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(57) A system and method for performing SRNS re- 
location in a communication system transmits radio re- 
source Information including a clpheringparameterfrom 
a source RNC to a larget RNC, modifies the ciphering 
parameter to coincide with a deciphering parameter 
which a user terminal uses when out-of-sequence data 
is received, ciphers a data unit based on the modified 
ciphering parameter, and transmits the ciphered data 
unit from the target RNC to the user terminal. The meth- 
od may be modified to operate in UM mode or Am mode 
and to transmit data over one of several radio bearers. 
In accordance with another embodiment, the system 
and method transmits radio resource information from 
a source RNC to a target RNC and then transmits a data 
unit from the target RNC to a user terminal In this case, 
the data unit including a transmission sequence number 
which consecutively follows a transmission sequence 
unmber of a data unit last transmitted from the source 
RNC to the uer terminal. Jn accordance with another em- 
bodiment, the system and method resets ciphering and 
stale variables in a target RNC and then transmits a 
message instructing a user terminal to reset a decipher- 
ing and state variables to the same or similar values. All 
the embodiments are advantageous because they en- 
sure successful communications will take place be- 
tween the target RNC and user terminal after a serving 
radio network sub-system relocation procedure Is per- 
formed 
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Description 

BACKGROUND OF THE INVENTION 



1 Field of the invention 

[O0O1J This invention generally relates to wireless 
communication systems, and more particularly to a sys- 
tem and method for performing a serving radio network 
sub-system (SRNS) relocation procedure In a commu- 
nications system 

2. Background of the Relate Art 

[0002] A universal mobile telecommunications sys- 
tem (UMTS) Is a third generation mobile communication 
system that has evolved from a standard known as Glo- 
bal System for Mobile communications (GSM) This 
standard is a European standard which aims to provide 
an improved mobile communication service based on a 
GSM core network and wideband code division multiple 
access (W-CDMA) technology in December, 1998, the 
ETSI of Europe, the ARiB/TTC of Japan, the T1 of the 
United States, and the TTA of Korea formed a Third 
Generation Partnership Project (3GPP) for the purpose 
of creating a specification for standardizing the UMTS 
[O0O3] The work towards standardizing the UMTS 
performed by the 3GPP has resulted in the formation of 
five technical specification groups (TSG), each of which 
is directed to forming network elements having inde- 
pendent operations More specifically, each TSG devel- 
ops > approves, and manages a standard specification 
in a related region. Among them, a radio access network 
(RAM) group (TSG- RAN) develops a specification for 
the function, items desired, and interface of a UMTS ter- 
restrial radio access network (UTRAN), which is a new 
RAN for supporting a W-CDMA access technology in 
the UMTS 

[0004] The TSG-RAN group includes a plenary group 
and four working groups Working group 1 (WG1) de- 
velops a specification for a physical layer (a first layer). 
Working group 2 (WG2) specifies the functions of a data 
link layer (a second layer) and a network layer (a third 
layer) Working group 3 (WG3) defines a specification 
for an interface among a base station in the UTRAN, a 
radio network controller (RNC). and a core network Fh 
naily, Working group 4 (WG4) discusses terms desired 
for a radio link performance and items desired (or radio 
resource management 

[0005] Figure 1 shows a structure of a 3GPP UTRAN 
to which the present Invention may be applied This 
UTRAN Includes one or more radio network sub-sys- 
tems (RNS) Each RNS includes an RNC and one or 
more Nodes B (eg, a base station) managed by the 
RNCs RNCs are connected to a mobile switching cent- 
er (MSG) which performs line exchange communica- 
tions with the GSM network The RNCs are also con- 
nected to a serving general packet radio service support 



node (SGSN) which performs packet exchange commu- 
nications with a general packet radio service (GPRS) 
network. 

10006] Nodes B are managed by the RNCs, receive 

5 information sent by the physical layer of a terminal (e 
g , mobile station, user equipment and/or subscriber 
unit) through an uplink, and transmit data to a terminal 
through a downlink Nodes B, thus, operate as access 
points of the UTRAN for the terminal. 

to [0007] The RNCs perform functions which Include as- 
signing and managing radio resources An RNC that di- 
rectly manages a Node B is referred to as a control RNC 
(CRNC). The CRNG manages common radio resourc- 
es A serving HNC (SRNC), on the other hand, manages 

15 dedicated radio resources assigned to the respective 
terminals The CRNC can be the same as the SRNC. 
However, when the terminal deviates from the region of 
the SRNC and moves to the region of another RNC, the 
CRNC can be different from the SRNC Because the 

so physical positions of various elements in the UMTS net- 
work can vary, an interface for connecting the elements 
Is necessary Nodes B and the RNCs are connected to 
each other by an Sub interface Two RNCs are connected 
to each other by an fur interface. An interface between 

2S the RNC and a core network is referred to as lu 

£0098] Services provided to the UE may generally be 
classified Into circuit-switching services and packet- 
switching services A voice telephone service may be 
included In the circuit-switching service and a Web- 

30 browsing service may be included In a packet-switching 
service through an internet connection. The circuit- 
switching service is connected to an MSG of the core 
network, and this MSG is connected to a gateway mobile 
switching center (GMSC) for communicating with one or 

35 more external networks. The GMSC manages the con- 
nections between the MSG and the external networks 
[0009] The packet-switching service is connected to 
a serving general packet radio service (GPRS) support 
node (SGSN), this node is connected to a gateway 

40 GPRS support node (GGSN) of the core network. The 
SGSN communicates packets between the SRNC and 
GGSN, and the GGSN manages connections between 
the SGSN and another packet-switching network such 
as the internet . 

4& [00101 A variety of interfaces are provided for per- 
forming mutual data exchanges between these network 
components. An interface between an RNC and the 
core network is known as an lu interlace When the lu 
is connected to the packet-switching domain, It is called 

5f? an lu PS Interface, and when the lu is connected to the 
circuit-switching domain It Is called a lu CS interface. 
[0011] Figure 2 shows a structure of a radio access 
Interface protocol between a terminal which operates 
• based on a 3GPP RAN specification and a UTRAN The 

55 radio access Interface protocol is horizontally formed of 
a physical layer (PHY), a data link layer, and a network 
layer and is vertically divided into a control plane for 
transmitting control information and a user plane for 



2 



3 



EP 1 337 125 A2 



4 



transmitting data information. The user plane is a region 
to which traffic information of a user such as voice or an 
IP packet is transmitted- The control plane Is a region to 
which control Information such as an interface of a net- 
work or maintenance and management of a calf is trans- 
mitted 

[0012] * n Figure 2 S protocol layers can be divided into 
a first layer (L1), a second layer (L2), and a third layer 
(L3) based on three lower layers of an open system in- 
terconnection (OSI) standard model well known in a 
communication system The first layer (L 1 ) operates as 
a physical layer (PHY) for a radio Interface and is con- 
nected to an upper medium access control (MAC) layer 
through one or more transport channels. The physical 
layer transmits data delivered to the physical layer 
(PHY) through a transport channel to a receiver using 
various coding and modulating methods suitable for ra- 
dio circumstances. The transport channel between the 
physical layer (PHY) and the MAC layer is divided into 
a dedicated transport channel and a common transport 
channel based on whether it Is exclusively used by a 
single terminal or shared by several terminals 
[0Q13J The second layer 12 operates as a data link 
layer and lets various terminals share the radio resourc- 
es of a W-CDMA network The second layer L2 Is divid- 
ed into the MAC layer, a radio fink control (RLC) layer, 
a packet data convergence protocol (POOP) layer, and 
a broadcast/multicast control (BMC) layer 
[0014} The MAC layer delivers data through an appro- 
priate mapping relationship between a logical channel 
and a transport channel The logical channels connect 
an upper layer to the MAC layer Various logical chan- 
nels are provided based on the kind of transmitted in- 
formation, in general, when information of the control 
plane is transmitted, a control channel Is used. When 
information of the user plane is transmitted, a traffic 
channel is used The MAC layer is divided two sub lay- 
ers according to performed functions The two sub-lay- 
ers are a MAC-d sub-layer that is positioned in the 
SRNC and manages the dedicated transport channel 
and a MAC-c/sh sub-layer that ts positioned in the 
CRNC and manages the common transport channel 
[0015] The RLC layer forms an appropriate RLC pro- 
tocol data unit (PDU) suitable for transmission by the 
segmentation and concatenation functions of an RLC 
service data unit (SOU) received from an upper layer 
The RLC layer also performs an automatic repeat re- 
quest (ARQ) function by which an RLC PDU lost during 
transmission is re-transmitted. The RLC layer operates 
in three modes: a transparent mode (TM), an unac- 
knowledged mode (UM), and an acknowledged mode 
(AM) The mode selected depends upon the method 
used to process the RLC SOU received from the* upper 
layer An RLC buffer stores the RLC SDUs or the RLC 
PDUs received from the upper layer. A more detailed 
explanation of the modes of operation of the RLC layer 
m\\ follow. 

[0016] The packet data convergence protocol (PD- 



CP) layer rs an upper layer of the RLC layer which allows 
data Hems to be transmitted through a network protocol 
such as IPv4 or IPv6 A header compression technique 
for compressing and transmitting the header information 
5 In a packet can be used for effective transmission of the 
iP packet, 

[0017] The broadcast/multicast control (BMC) layer 
allows a message to be transmitted from a celt broad- 
cast center (CBC) through the radio interface The main 
to function of the BMC layer is scheduling and transmitting 
a cell broadcast message to a terminal In general, data 
is transmitted through the RLC layer operating in the un- 
acknowledged mode. 

[001 8] The PDCP layer and the BMC layer are con- 
's nected to the SGSN because a packet exchange meth- 
od is used, and are located only in the user plane be- 
cause they transmit only user data. Unlike the PDCP 
layer and the BMC layer, the RLC layer can be Included 
m the user plane and the control plane according to a 
so layer connected to the upper layer When the RLC layer 
belongs to the control plane, data is received from a ra- 
dio resource control (RRC) layer 
[0019] In general, the transmission service of user da- 
ta provided to the upper layer by the second layer (L2) 
ss in the user plane Is referred to as a radio bearer (RB). 
The transmission service of control Information provided 
to the upper layer by the second layer (12) in the control 
plane is referred to as a signaling radio bearer (SRB), 
As shown in Figure 2, a plurality of entities can exist in 
30 the RLC and PDCP layers This Is because a terminal 
has a plurality of RBs, and one or two RLC entitles and 
only one PDCP entity are generally used for one RB. 
The entitles of the RLC layer and the PDCP layer can 
perform an Independent function In each layer 
35 [0020] The RRC layer positioned in the lowest portion 
of the third layer (L3) is defined only in the control plane 
and controls the logical channels, the transport chan- 
nels, and the physical channels in relation to the setting, 
the re-setting, and the cancellation of the RBs At this 
<to time, setting up the RB means processes of stipulating 
the characteristics of a protocol layer and a channel, 
which are required for providing a specific service, and 
setting the respective detailed parameters and opera- 
tion methods . It is possible to transmit control messages 
45 received from the upper layer through a RRC message. 
£002 1 j Operation of the radio bearer and th e RLC lay- 
er will be now described In detail. As previously dis- 
cussed, a radio bearer (RB) is a transmission service 
which delivers user data in the user plane to an upper 
st? layer through the second layer L2. The transmission 
service which delivers control Information in the control 
plane to the upper layer through the second layer L2 Is 
defined as a signaling radio bearer (SRB) 
[0022] As previously noted, the RLC layer operates in 
55 one of three modes: transparent mode fTM), unac- 
knowledged mode (UM), and acknowledged mode 
(AM) 

[0023] When operating In the TM mode, header infor- 
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mation is not added to the RLC SOU received from the 
upper layer, no sequence number is attached to the RLG 
PDU and data re-transmission Is not performed, Also, 
though segmentation and reassembly of the RLC SOU 
are generally not performed, use of segmentation and 
reassembly when the radio bearer Is set up is deter- 
mined In certain circumstances. 
£0024] When operating in UM mode, re-transrnlssron 
of RLC PDUs is not performed even when a transmis- 
sion failure occurs The receiver does not request re- 
transmission of data instead, a different approach Is 
taken In UM mode, the RLC layer constructs RLC PDUs 
by segmenting or concatenating RLC SDUs, and then 
attaching sequence numbers to the RLC PDUs The re- 
ceiver can restore lost data based on the sequence 
numbers by a re-assembly procedure. 
[0025] When operating in the AM mode, re-transmis- 
sion is used to support error-free transmission In the fol- 
lowing manner Status information corresponding to re- 
ceived RLC PDUs Is transmitted from the receiver in the 
form of a Status Report After receiving this report, the 
transmitter re-transmits unsuccessfully transmitted RLC 
PDUs 

[0026] More specifically, In AM made, the transmitter 
forms each RLC PDU From one or more RLC SDUs that 
have been received from art upper layer, and header In- 
formation, (e g sequence number and length Indica- 
tors) are then attached Since the size of an AM RLC 
PDU is fixed, the transmitter segments or concatenates 
one or more RLC SDUs to fit the PDU size. Then, the 
formed RLC PDU is stored In the transmission buffer 
The stored RLC PDUs are sequentially delivered to the 
MAC layer at a rate controlled by the MAC layer. Since 
each RLC PDU has its own sequence number, the re- 
ceiver can check which RLC PDUs are successfully re- 
ceived and which are not The receiver requests the re- 
transmission forthe unsuccessfully received RLC PDUs 
to the transmitter by the Status Report 
£0027] The AM retransmission procedure may be 
more clearly understood by the following example If the 
sequence numbers of the received RLC PDUs are #23, 
#24, #25, #32, and #34, the receiver considers that RLC 
PDUs having the sequence numbers of #26 to #31 and 
#33 are lost during transmission The receiver then 
sends a Status Report to the transmitter, and the trans- 
mitter checks the Status Report, and retransmits the 
unsuccessfully transmitted RLC PDUs, he. #26 to #31 
and #33. 

[0028] Figure 3 shows the structure of an RLC PDU 
of AM or UM mode used in the RLC layer The RLC PDU 
is comprised of a header and a payload The header 
shown Includes a sequence number and a length Indi- 
cator. The sequence number Is used as an Identifier of 
the corresponding RLC PDU, and the length Indicator 
indicates a boundary of the RLC SDU The sequence 
numbers may be. for example, 7 (seven) bits for UM 
mode, and 12 (twelve) bits for AM mode, A 1 (one) bit 
E field may be includedto Indicate whether the next field 



is the length Indicator or data 

[00291 The length indicator is used to indicate the 
boundary of each RLC SDU ending within the RLC PDU. 
Therefore, the length indicator may not be present if the 

5 RLC SDU is not ended within the RLC PDU The length 
Indicator may also ba used for other purposes . For ex- 
ample, the length indicator may be used as a padding 
indicator and/or a data start indicator Padding is used 
to fill the whole RLC PDU when there is no RLC SDU to 

10 be concatenated. The padding can have any value and 
the receiver and the sender disregard it. When used as 
a data start indicator the length indicator may Indicate 
that the RLC SDU begins in the beginning of the RLC 
PDU 

is [0030 j The date start I ndicator is useful because it can 
prevent additional loss of data In the UM RLC For ex- 
ample, assume that an RLC PDU of sequence number 
#4 Is lost and an RLC PDU of sequence number #5 is 
received Assume further that a new RLC SDU begins 

20 at the beginning of the PDU of sequence number #5 and 
ends within the PDU of sequence number #5 In Ibis 
case, because the RLC SDU begins at the beginning of 
the PDU of sequence number #5, the data start indicator 
Is present at the headerof the PDU of sequence number 
#5 But, if the data start indicator Is not present, the re- 
ceiver RLC layer considers that only continued seg- 
ments of an RLC SDU contained in the RLC PDU of se- 
quence number #5 is received In this case, the receiver 
discards the segments because the receiver thinks that 

30 the entire RLC SDU has not been received.. 

£0031] Figure 4 shows an exemplary snapshot of the 
status of an RLC buffer As shown, the RLC PDUs are 
sequentially stored in the buffer and the successfully 
transmitted RLC PDUs are deleted from the buffer As 
shown, the RLC layer uses state variables for managing 
the transmission of data using the RLC buffer. 
[0032] When operating in AM mode, the RLC layer us- 
es a state variable VT(S) to indicate the sequence 
number of the next RLC PDU to be transmitted for the 

40 first time, and a state variable VT(A) to indicate the se- 
quence number of the first RLC PDU to be positively 
acknowledged by the receiver The status of the buffer 
therefore Indicates that the transmitter has transmitted 
RLC PDUs up to the PDU of sequence number of VT 

*5 {S)-1 and has received positive acknowledgments up to 
the RLC PDU of VT(A)-t from the receiver 
[0033} When operating in the UM mode, the RLC lay- 
er uses a state variable VT(US) which is similar to VT 
(S) In AM mode. That Is, VT(US) indicates the sequence 

so number of the next RLC PDU to be transmitted Howev- 
er, since there Is no feedback from the receiver in UM 
mode, the state variable such as VT(A) is not defined 
[0034] In both modes of operation . the initial value of 
the state variables may be set to 0 (zero) When the RLC 

55 layer Is established, re-estabKshed or reset, the state 
variables are set to this Initial value 
[0035] Returning now to radio communications proto- 
col shown in Figure 2, as previously Indicated, the serv- 
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ice provided to the upper layer by the second layer 12 
in the control plane is defined as a signaling radio bearer 
(SRB). In operation, all RRC messages are exchangee? 
between the terminal and the RNC through the signaling 
radio bearers SRBs Using the BBC messages, the 5 
RNC can setup, modify, and release Ihe radio bearers 
as needed In order to, for example, perform an SRNS 
relocation procedure, the details of which are described 
in greater detail below 

[0036] Signaling radio bearer {SRB) characteristics « 
as previously indicated are determined based on the 
mode of operation of Che RLC and the type of logical 
channel used A common control channel (CCCH) and 
dedicated control channel (DCCH} are used for the 
SRBs CCCH is a logical channel carrying common con- 
trot Information to several terminals Since CCCH is a 
common logical channel, CCCH contains a UTRAN ra- 
dio network temporary identity (U-RNTI) to Identify a 
specific terminal The DCCH is a logical channel carry- 
ing dedicated control information to a specific terminal so 
{0037] The characteristics of each type of SRB are as 
Follows. 

{0038J SRB0: For the uplink (UL)TM RLC is used, and 
for the downlink (DL)UM RLC is used The logical chan- 
nel used for the SRB0 Is CCCH & 
[Q039J SRB1 : UM RLC is used, and the logical chan- 
nel is DCCH 

[00401 SRB2: AM RLC Is used, and the logical chan- 
nel is DCCH The SRB2 carries only the messages gen- 
erated In the RRC layer The SRB2 does not carry the 
upper layer messages 

[0041] SRB3: AM RLC is used, and the logical chan- 
nel is DCCH. The SRBS carries the messages received 
from the upper layer. 

[0042] SRB4: AM RLC Is used, and the logical chan- 05 
net is DCCH The SRB4 also carries the messages re- 
ceived from ihe upper layer The difference is that the 
SRBS carries higher priority messages while the SR84 
carries lower priority messages 

[0043] SRB5-31: TM RLC is used, and the logical 40 
channel is DCCH . These SRBs are optionally used. 

SRMS Relocation Procedure 

[0044] Figure 5 Is a diagram showing how a serving « 
radio network sub-system (SRNS) procedure may ba 
performed in a packet-switching based service domain 
As shown, this procedure involves changing the RNS 
serving a user terminal from one RNS (or RNC) to an- 
other When making this change, It Is preferable to es- 
tabJlsh the shortest route between the temninal and core 
network by changing the lu connection point As is fur- 
ther shown, changing the lu connection point may in 
some instances cause the core network to switch from 
one SGSN (Old SGSN) to another (New SGSN) for pur- bs 
poses of performing communications with the user ter- 
minal The SRNS relocation procedure may also be per- 
formed in the circuit-switching based service domain 



[0045] An SRNS relocation procedure may be per- 
formed for at least the following reasons: 

* Connection Point Change: Relocation is performed 
to move the UTRAN to a ON connection point at the 
UTRAN side from the source RNC to the target 
RNC 

* Combin e d Har d Handover: Relocation Is performed 
to move the UTRAN to a CM connection point at the 
UTRAN side from the source RNC to the target 
RNC, while performing a hard handover decided by 
the UTRAN. 

* Combined Cell/URA Update:: Relocation Is per- 
formed to move the UTRAN lo the CN connection 
point at the UTRAN side from the source RNC to 
the target RNC, while performing a cell re-selection 
in the UTRAN . 

As will be discussed in greater detail, an SRNS reloca- 
tion procedure may require the use of different radio 
bearers depending upon the mode of operation of the 
RLC layer. 

[0046] SRNS relocation Is usually classified Into two 
cases: (1) terminal not involved case (Case \) and (2) 
terminal involved case (Case II)., In Case I, SRNS relo- 
cation Is initiated by a network's own decision and the 
terminal docs not know whether the SRNS relocation Is 
performed until the relocation procedure Is terminated.. 
In Case 11, SRNS relocation is Initiated as a resull of the 
terminal's ceil change (eg , handover) request and the 
terminal knows the SRNS relocation at Ihe beginning of 
the procedure . Though Cases \ and II are different in 
that one is Involved with the terminal and the other is 
not, the two cases have no substantial difference with 
respect to the SRNS relocation procedure.. A more de- 
tailed explanation of this procedure now follows 
[0047] During the SRNS relocation procedure, vari- 
ous signaling messages are exchanged between the 
terminal and one RNC, between the one RNC and an- 
other RNC, and between one of the RNCs and the core 
network. 

[0048] Figure 6 shows the exchange of signaling mes- 
sages that takes place between the terminal end core 
network In the SRNS relocation procedure of the UMTS 
In this exchange, the "source RNC" is the RNC that 
plays the role of the SRNC before SRNS relocation and 
the "target RNC" is the RNC that plays the rote of the 
SRNC after SRNS relocation Likewise, the "old SGSN 1 ' 
Is the SGSN before the relocation procedure and the 
"new SGSN" Is the SGSN after the relocation proce- 
dure Though the old and now SGSNs are shown to be 
different, the old SGSN and new SGSN may be the 
same in certain circumstances Moreover, the proce- 
dure shown in Figure 6 may be applied to both Case I 
and Case 11 

[0049] The steps of the SRNS relocation procedure 
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will now be summarized.. In an initial step, step 1, the 
source RNC decides to perforin an SRNS relocation Ei- 
ther Case I or Case II may be used to trigger the relo- 
cation procedure, 

[0050] In step 2, the source RNC sends a Relocation 
Required message to the old SGSN. The Relocation 
Required message includes information for performing 
for example, relocation co-ordination, security function- 
ality, RRC protocol context Information, and the terminal 
capabilities. 

[0051] In step 3, the old SGSM determines from the 
Relocation Required message if the SRNS relocation Is 
Jntra-SGSN or Inter-SGSN SRNS relocation An in- 
tra-SGSN procedure is performed when the old and new 
SGSNs are the same, and an Inter-SGSN procedure Is 
performed when the two are different A Forward Relo- 
cation Request message is applicable only in the case 
of Inter-SGSN SRNS relocation 

[0052] In step 4 t the new SGSN sends e Relocation 
Request message to the target RNC so that the neces- 
sary resources are allocated between the target RNC 
and the new SGSN After all necessary resources are 
successfully allocated, the target RNC sends the Relo- 
cation Request Acknowledge message to the new SG- 
SN. 

[0053J In step 5, when a resource for the transmission 
of user data between the target RNC and the new SGSN 
have bssn allocated and the new SGSN Is ready for 
SRNS relocation, the Forward Relocation Response 
message fs sent from the new SGSN to old SGSN.. 
[0054] In step 6, the old SGSN continues SRNS relo- 
cation by sending a Relocation Command message to 
the source RNC The source RNC is ready for forward 
downlink user data directly to the target RNC 
[0055] In step 7 t when the source RNC is ready for 
data-forwarding, it triggers execution of SRNS reloca- 
tion by sending a Relocation Commit message to the 
target RNC . 

[0056] In step 8 r the source RNC begins to forward 
data for the radio access bearers The data forwarding 
may be carried out through the lu interface, which 
means that data is not directly exchanged between the 
source RNC and the target RNC but through the core 
network 

[0057] In step 9, the target RNC sends a Relocation 
Detect message to the new SGSN When the Reloca- 
tion Detect message is sent, the target RNC starts 
SRNC operation 

{005BJ In step 1 0, the target RNC sends a UTRAN mo- 
bility Information (Case 1) message or a Ceil/URA 
(UTRAN registration area) update (Case 11} message to 
the terminal. Both messages contain terminal Informa- 
tion elements and core network Information elements 
The terminal Information elements include new U-RNTl 
used for the identification of the terminal in the target 
RNC. The core network information elements include lo- 
cation area identification and routing area identification 
information. 



[0059] Upon receipt of the UTRAN Mobility Informa- 
tion message the terminal can start sending uplink (UL) 
user data to the target RNC When the terminal has 
reconfigured itself, it sends the UTRAN Mobility fnfor- 
5 rnatlon Confirm message to the target RNC This indi- 
cates that the terminal Is also ready to receive downlink 
(QL) data from the target RNC 

[0060] in step 11 , upon receipt of the Relocation De- 
tect message the core network switches the user plane 

10 from source RNC to target RNC In the case of an In- 
ter-SGSN SRNS relocation, the new SGSN sends Up- 
date PDF Context Request messages to the GGSNs 
concerned . The GGSNs update their POP context fields 
and return an Update PDP Context Response 

is [0061] In step 12, when the target RNC receives the 
UTRAN Mobility Information Confirm message, (i.e., the 
new U-RNT1 is successfully exchanged with the terminal 
by the radio protocols), the target RNC sends the Relo- 
cation Complete message to the new SGSN The pur- 

20 pose of the Relocation Complete message is to indicate 
by the target RNC completion of the relocation of the 
SRNS to the core network In the case of an inter-SGSN 
SRNS relocation, the new SGSN signals the old SGSN 
of the completion of the SRNS relocation procedure by 

2$ sending a Forward Relocation Complete message. 
[O0S2J in step 1 3, upon receiving th e Relocation Com- 
plete message or the Forward Relocation Complete 
message, the old SGSN sends an lu Release Command 
massage to the source RNC so that the lu connection 

30 between the source RNC and the old SGSN is released. 
[0OS3] Figure 7 shows the steps of the SRNS reloca- 
tion procedure including the exchange of RRC messag- 
es between the UTRAN and the terminal. In this figure, 
RRC messages are transmitted at steps 1 , 7, and 8, and 

35 the UTRAN can either be the source RNC or target RNC 
depending on the case Also, UE refers to user equip- 
ment and therefore may include a user terminal. The 
RRC messages transmitted in this procedure are de- 
scribed as follows. 

40 

(1) Cell Update message and Celi Update Conf irm 
message: When the terminal moves to a new cell, 
a Ceil Update message is sent from the terminal to 
the UTRAN If the UTRAN decides to perform 

45 SRNS relocation, the target RNC sends the Celi Up- 
date Confirm message to the terminal as a re- 
sponse to the Call Update message The Celt Up- 
date Confirm message contains the new U-RNTI, 
which indicates to the terminal the SRNS relocation 

so procedure being performed The Cell Update mes- 
sage Is transmitted through SRB0 using TM RLC, 
and the Cell Update Confirm message is through 
either SRB0 or SRB1 using UM RLC 

(2) URA Update massage and URA Update Confirm 
55 message: A URA (UTRAN registration area) is an 

area comprised of one or several cells, and Is inter- 
nally known to the UTRAN . The URAs may partially 
overlap In order to prevent a ping-pong effect of the 
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terminal.. Therefore, one cell can belong to one ar 
more URAs. The terminal knows the current URA 
identity from the URA list broadcast In each cell and 
performs the URA update procedure whenever the 
URA is changed 

The DBA update procedure is initiated when 
the terminal sends the URA Update message to the 
UTRAN. The UTRAN transmits the URA Update 
Confirm message in response to the URA Update 
message to the terminal in order to Inform the ter- 
minal of the new URA identity The URA Update 
Confirm message Includes a new U-RMT1 which is 
the same as in the Cell Update Confirm message. 
The URA Update message is transmitted through 
SRBO using TM RLC. and the URA Update Confirm 
message is transmuted through SRBO or SRB1 us- 
ing UM RLC. 

£3) UTRAN Mobility Information massage and 

UTRAN Mobility Information Confirm message : The 
UTRAN Mobility information message is used when 
the UTRAN assigns a new U-RNTI to the terminal 
or when mobility information is transmitted The ter- 
minal transmits UTRAN Mobility Information Con- 
firm message in response A Her successfully trans- 
mitting the UTRAN Mobility Information Confirm 
message, the target RNC and the terminal estab- 
lish/re-establish the PDCP and RLC entities using 
CPDCP-CONFIG-Req and CRLC-CONRG-Req 
commands, respectively The UTRAN Mobility In- 
formation message Is transmitted through SRB1 us- 
ing UM RLC or SRB2 using AM RLC The UTRAN 
mobility Information Confirm message is transmit- 
ted through SRB2 using AM RLC 

Ciphering 

[0064} The SRNS relocation procedure has been de- 
scribed in terms of the steps taken in both the UMTS 
system and the UTRAN From this description, it is clear 
that the SRNS relocation procedure is primarily based 
on the exchange of messages between the terminal and 
RNC, and between the RNC and the core network 
Among these messages, RRC messages exchanged 
between the tormina! and the RNC are usually ciphered 
for the sake of security 

[0065] in some cases, the ciphered RRC messages 
cannot be deciphered in the receiver because the ci- 
phering parameters are different between the terminal 
and the UTRAN \n order to gain a better understanding 
of this problem, the ciphering method in general must 
first to be considered. 

[0066] Ciphering is a method which prevents unau- 
thorized access of data, for example, as a result of 
eavesdropping. Because unique ciphering parameters 
exist between the terminal and the RNC, a user who 
does not know the ciphering parameters cannot deci- 
pher the data 

[0067] The ciphering method adopted by the 3GPP is 



performed in the RLC layer or the MAC layer according 
to the RLC mode of operation. That is, when the RLC 
mode is AM or UM, ciphering Is performed in the RLC 
layer When the RLC mode is TM. ciphering is per- 
5 formed In the MAC layer Preferably, in this system ci- 
phering is applied only for the DCCH and DTCH chan- 
nels 

[Q068] During this ciphering method, a MASK used for 
ciphering is generated based on various input parame- 

10 ters The MASK Is then added to RLC PDUs or MAC 
SDUs to generate the ciphered data, in the user termi- 
nal, the same MASK is used to decipher the data. 
[0069] Figure a shows steps included in the ciphering 
process Here, PLAINTEXT BLOCK is the data before 

is ciphering and KEYSTREAM BLOCK is a ciphering 
MASK The PLAINTEXT BLOCK is ciphered to Cl- 
FHERTEXT BLOCK through a bit operation with the 
KEYSTREAM BLOCK. Then, the ciphered CIPHER- 
TEXT BLOCK m transmitted to a radio interface. After 
receiving the CIPHERTEXT BLOCK, the receiver deci- 
phers it by applying the KEYSTREAM BLOCK that is 
the same MASK as in the transmitter. That Is, if the ci- 
phered data is extracted during transmission, the data 
cannot be deciphered unless the KEYSTREAM BLOCK 

25 is known 

[OD70] The core technology of ciphering lies in the 
generation of the KEYSTREAM BLOCK, i e the cipher- 
ing MASK To achieve effective results, the MASK 
should have the following characteristics. First, genera- 
te tlon of the MASK by reverse tracing should be impossi- 
ble Second, each radio bearer RB should have its own 
MASK^ Third, the MASK should continuously change 
over time, 

[0071] Among the various ciphering algorithms thai 
S5 exist, a method referred to as FS has been adopted by 
3GPP communications systems. The F8 algorithm gen- 
e rates the KEYSTREAM BLOCK using input parame- 
ters including: 

40 CK (Ciphering key, 128 bits): There is one CK^ for 
a circuit switching based service domain and one 
CK PS for a packet-switching based service domain . 
BEARER (Radio Bearer identifier, Sbils): One value 
exists for each RB. 

45 DIRECTION (Direction Identifier, tbit): Indicates 
the direction of the RB It is set to 0 for uplink and 
1 for downlink 

LENGTH (16blts): Indicates the length of the KEY- 
STREAM BLOCK, I.e. the generated MASK 

bo COUNT-C (32bits): A ciphering sequence number 
For RBs using AM or UM RLC, one COUNT-C is 
used for each R8 For RBs using TM RLC, one 
COUNT-C value is used for ail the RBs Those 
skilled In the art can appreciate that the bit and other 

55 values provided above are preferred values and 
may be changed if desired 

[0072} Among the ciphering input parameters, 
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COUNT-C is the only time-varying parameter That is, 
different COUNT-C values are used for each PDU Oth- 
er ciphering input parameters are fixed parameters and 
therefore the same values may be used for these pa- 
rameters for alt PDUs In a data stream The COUNT-C 
parameter is divided into two parts; a forward part and 
a rear part The forward part includes a long sequence 
number and the rear part Includes a short sequence 
number 

[0073J Figure & shows detailed structures of the 
COUNT-C parameterforthevahousrnodes of operation 
of the RLC layer The respective structures are as fol- 
lows: 

T M i PLC case 

long sequence number: MAC-d Hyper Frame 
Number (HFN) of 24 bits 
short sequence number: Connection Frame 
Number (CFN) of B bits 

UM RLG case 

long sequence number: RLC Hyper Frame 
Number (HFN) of 25 bits 
short sequence number: RLC UM Sequence 
Number (SN) of 7 bits 

AM RLC case 

long sequence number: RLC Hyper Frame 
Number (HFN) of 20 bits 
short sequence number; RLC AM Sequence 
Number (SN) of 12 bits 

[0074] The CFN is a counter for synchronizing the 
transport channels of the MAC layer between the termi- 
nal and the UTRAN, The CFN may have a value be- 
tween 0 and 255 and it increases by one for each radio 
frame (10ms) 

[00751 The RLC SN Is a sequence number used for 
identifying each RLC PDU . For UM RLC, the RLC SN 
has a value between 0 and 127 (7 bits) For AM RLC, 
the RLC SN has a vafue between 0 and 4095 (12 bits) 
The RLC SN increases by 1 for each RLC PDU 
[0076J Since a short sequence number is too short to 
be used alone for COUNT-C, a long sequence number 
known as HFN is added in front of the short sequence 
number. More specifically, the HFN corresponds to the 
MSBs (Most Significant Bits) and short sequence 
numbercorresponds to the LSBs (Least Significant Bits) 
of the COUNT-C. Therefore, HFN Is increased by 1 
when the short sequence number wraps around to 0 
The adjustment of this HFN is one of the factors which 
causes ciphering problems to occur In related art sys- 
tems, details of which will now be discussed. 
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Drawbacks of Ralate&Art SRNS Relocation 
Procedures 

[O077] Ciphering problems are usually caused when 
5 the HFNs become out of synchronization between the 
RLC entities of the terminal and the RNS (or PNC) in 
the UTRAN This synchronization problem is mainly at- 
tributable to the COUNT-C pa rameter More specifically, 
as previously discussed, all ciphering parameters ex- 
10 cept COUNT-C are fixed parameters and therefore may 
remain synchronized throughout the connection. The 
short sequence number (i.e. the LSBs of the COUNT-C) 
is also synchronized because, tor TM RLC, the CFN is 
known to both the terminal and the UTRAN and, for UM 
15 and AM PLC, the RLC SN is Included in the PDU header 
and transmitted through the radio Interface For TM 
RLC, the long sequence number corresponding to HFN 
is also synchronized because the CFN is calculated 
from the SFN (System Frame Number) which is contin- 
ue* uousiy broadcast in a cell For UM and AM RLC, how- 
ever, the HFN Is sometimes out-of ^synchronization due 
to tost or re-transmitted RLC PDUs This condition is ex- 
plained in greater detail below 

[O078J Under normal conditions, the HFN is never ex- 

25 changed and is locally managed by the terminal and the 
UTRAN The locally managed HFNs may become out- 
of-synchronizatlon for UM and AM RLC modes when 
RLC PDUs are lost or re-transmitted, as previously men- 
tioned If the HFN values managed by the terminal and 

30 the UTRAN become different, then the MASKs used in 
the terminal and the UTRAN also become different As 
a result, the ciphered data cannot be deciphered in the 
receiver. Thus, once the HFNs become oul-of-synchro- 
nization, data transmission cannot be successfully per- 

35 formed until the HFNs are synchronized. 

[0079] The problems In the related-art SRNS reloca- 
tion procedure are caused when this ciphering problem 
(i.e., unsynchronized HFNs) arises in UM and AM RLC 
operation, in Figure 7, these problems affect steps 7 and 

40 8 - The manner in which the steps are adversely affected 
will now be described in detail. (Note that step 1 has no 
ciphering problem since the PRC message is transmit- 
ted using TM RLC), 

4$ Problems In Step 7. 



[0080] In Case f (UE not involved) and Case It (UE 
involved), PRC messages are transmitted to the termi- 
nal using an appropriate serving radio bearer SRB The 

50 RLC layer In the target RNC Is newly generated and the 
status variables and timers are initialized . As a result of 
this initialization, the sequence number of the RLC PDU 
transmitted from the RLC layer in the target RNC to the 
terminal is initialized to 0 (zero) The terminal RLC layer, 

55 however, may be expecting the next PDU K receives to 
have a different sequence number The possible prob- 
lems in transmitting PRC messages resulting from this 
discrepancy wilt be described for each of these cases 
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(1) UTRAN Mobility Information Message is Trans- 
rnlUed ThroURh SRB1: In this case, the relocation 
procedure is performed during a UM RLC made of 
operation During this procedure, the UTRAN HFN 
is transferred from the source RNC to the target 
RNC and the target RNC transmits a protocol data 
unit (PDU) including the UTRAN HFN to the termi- 
nal As previously explained, however, before the 
PDU is transmitted Its sequence number is initial- 
ized to some number, e g ., zero. In most cases, this 
initialized value does not correspond to the se- 
quence number of the next PDU the terminal ex- 
pects lo receive. As a result, when the terminal re- 
ceives the PDU with its initialized sequence 
number, it concludes that one or more PDUs have 
not been successfully received, e g , there are 
some missing PDUs. The terminal will therefore op- 
erate based on the assumption that an RLC se- 
quence-number wrap around condition has oc- 
curred When this condition Is detected, the trans- 
mitter RLC will alter Its ciphering information by In- 
cremanting its HFN parameter by one This 
presents the following problem 

When the relocation procedure caused the 
serving RNS (SRNS) to change from the source 
RNC to the target RNC, the value of the HFN pa- 
rameter was not changed. As a result, the target 
RNC will transmit PDUs with the original UTRAN 
HFN value The terminal, however, will attempt to 
decipher these PDUs with the newly Incremented 
HFN value . Because the terminal and UTRAN are 
operating based on different HFN values, the termi- 
nal and UTRAN (target RNC) are considered to be 
out of synchronization and the transmitter will not 
be able to decipher any PDUs from the UTRAN. 

(2) UTRAN Mobility information Message is Trans- 
mitted Through SRB2: In this case, the relocation 
procedure is performed during AM RLC mode of op- 
eration, and the terminal RLC only accepts PDUs 
having sequence numbers that fall within a valid 
range, which is maintained for purposes of efficient 
management of data re-transmissions This valid 
range is defined by the size and position of a receiv- 
ing window maintained by the terminal receh/er dur- 
ing AM operation. When the terminal receives RLC 
PDUs which He outside of the receiving window, the 
terminal just discards these PDUs. 

During the relocation procedure, the next PDU 
transmitted to the terminal has a sequence number 
which has been initialized to zero if this sequence 
number Hes outside of the receiving window of the 
transmitter, it will be immediately discarded How* 
ever, even if the sequence number lies within the 
range of the receiving window, the PDU wilt not be 
able to be deciphered by the transmitter This is be- 
cause the next sequence number the terminal ex- 
pects lo receive does not correspond to the se- 
quence number of the received PDU . The terminal 



w9l therefore conclude that missing PDUs exist and 
that a wrap-around condition with respect to PDU 
sequence numbers has occurred When this condi- 
tion is detected, the transmitter RLC will alter Its ch 

5 pherlng information by Incrementing its HFN pa- 

rameter by one, thereby causing the HFN of the ter- 
minal and the HFN of the UTRAN to be different. 
This discrepancy will prevent the terminal from de- 
ciphering any data from the UTRAN 

10 (3) CeiRJRA Update Confirm Message Is |ransmjl : 
ted through SR81: In this case, the relocation pro- 
cedure is performed during UM RLC operation The 
same problem occurs as in (1 ) above, i e , the RRC 
messages transmitted from the target RNC in step 

15 7 cannot be deciphered by the terminal because of 
a discrepancy in HFN values which occurred as a 
result of the initialization of the sequence number 
of the next PDU transmitted from the UTRAN 

20 [0081] in all the above cases, the terminal and 
UTRAN will not be able to communicate after SRNS re- 
location has been performed unless and until the out- 
of-synchronization problem with regard to their HFNs is 
resolved Complications which arise in connection with 

25 step 8 will now be discussed 

Problems In Step 8, 

[0082] In Case 1 [UE not involved) and Case II (UE 
so involved), the terminal transmits a UTRAN Mobility Irv 
formation Confirm message through SRB2 when the re- 
location procedure Is performed during the AM RLC 
mode of operation The similar problems occur as indi- 
cated in (2) above for step 7 The difference is that the 
55 roles are reversed, I.e., the transmitter is the terminal 
RLC and the receiver is the target RNC RLC 
[0083] In view of the foregoing considerations, it is 
clear that there is a need for an improved system and 
method for performing an SRNS relocation procedure 
40 In a wireless communications system, and more specif- 
ically one which efficiently resolves deciphering discrep- 
ancies that arise between transmitting and receiving en- 
titles as a result of an Initialization performed during the 
relocation procedure 

45 

SUMMARY OF THE INVENTION 

[0084] An object of the invention Is to solve at least 
the above problems and/or disadvantages and to pro- 
so vide at least the advantages described hereinafter. 
[0085] Another object of the present invention is to 
provide a system and method for performing an SRNS 
relocation procedure in a wireless communications sys- 
tem In a manner which increases transmission efficien- 
ts cy compared with other systems which have been pro- 
posed. 

[0086] Another object of the present invention is to 
achieve the aforementioned object by efficiently resotv- 
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Ing deciphering discrepancies that arise between trans- 
mitting and receiving entitles whan an inlttef&atlon step 
Is performed In the relocation procedure. 
[00B7J Another object of the present invention fs to re- 
solve these deciphering discrepancies by ensuring that 
Ihe transmitting and receiving entitles operate using the 
same HFN parameter during or immediately after the 
relocation procedure is performed By coordinating this 
information, the out-of -synchronization problem thai 
other proposed systems experience is resolved in ac- 
cordance with one embodiment, the transmitting entity 
may be a UTRAN RNC and the receiving entity may be 
a user terminal, otherwise known as user equipment in 
the standards developed by the 3GPP, including but not 
limited to the universal mobile telecommunications sys- 
tem (UMTS) which Is one form of IMT-200O system In 
another embodiment, the transmitting entity may be the 
user terminal and the receiving entity may be a UTRAN 
BMC The present invention is also advantageous be- 
cause it may be applied to UM and AM modes of RLC 
operation . 

{0088} The foregoing and other objects of the inven- 
tion are achieved by providing a system and method 
which performs SRNS relocation in a mobile communi- 
cation system, and more specifically in a serving radio 
network sub-system which includes a radio network 
controller for managing a radio resource allocated to a 
terminal in the mobile communication system In ac- 
cordance with one embodiment, the method includes re- 
serving a requiring resource in a serving radio network 
sub-system relocation on a network; transmitting a radio 
resource control message corresponding to the serving 
radio network sub-system relocation to the terminal in 
order that the radio network controller communicates 
the termina I, and transmitting a response radio resource 
control message corresponding to the serving radio net- 
work sub -system relocation to the radio network control- 
ler to which the radio resource control message is trans- 
mitted. 

[0089] The radio network controller transmits data by 
setting a corresponding radio link layer and adjusting a 
frame number used for ciphering so that the terminal 
successfully restores ciphered data before the radio net- 
work controller transmits the corresponding radio re- 
source control message to the terminal The frame 
number Is increased by 1 more than a value used at a 
present time, and a unit data of the corresponding radio 
link layer is transmitted by ciphering A radio resource 
control layer may transmit a command for setting a link 
control layer and the frame number to the corresponding 
radio link control layer. 

[0090] In addition to these steps, an original radio net- 
work controller may perform the role of a serving radio 
network controller before the serving radio network sub- 
system relocation transfers status Information of a radio 
link control layer used at a present time to a target radio 
network controller This is performed so that the terminal 
successfully receives a serving radio resource control 



message before the target radio network controller 
transmits a radio resource control message correspond- 
ing to the serving radio network sub-system relocation 
to the terminal The transferred status information may 
6 include a parameter corresponding to the radio link con - 
trol layer operated In an unacknowledged mode Also, 
a first sequence number of a unit data of the radio link 
control layer including the radio resource control mes- 
sage corresponding to the serving radio network sub- 
to system relocation transferred from the target radio net- 
work controller to the terminal is transmitted by being 
set with a VT(US) of a parameter corresponding the ra- 
dio link control layer operated In the unacknowledged 
mode. 

t5 [0091] in accordance with another embodiment, the 
transferred status information includes a parameter or 
data corresponding to the radio link control layer oper- 
ated in an acknowledged mode Also, a first sequence 
number of unit data of ihe radio link control layer includ- 
ed ing the radio resource control message corresponding 
to the serving radio network sub-system relocation 
transferred from the target radio network controller to 
the terminal Is transmitted by being set with a VT(US) 
of a parameter corresponding the radio link control layer 
ss operated in the unacknowledged mode- The radio link 
control layer of the target radio network controller may 
transmit unit data of the radio link control layer being 
transmitting which is transferred from the original radio 
network controller 
30 [Q092] The original radio network controller finishes 
transmission of the radio resource control message be- 
ing transmitting orbetngwaited for being transmitted pri- 
or to transferring parameter corresponding to the radio 
link control layer operated in the acknowledged mode 
35 [0093] The radio link control layer of the target radio 
network controller transmits a receiving window move- 
ment command to a radio link control layer of the termi- 
nal in order to prevent a transmission of an unit data of 
the radio link control layer having a sequence number 
40 below a sequence number of VT{S)-1 . The radio re- 
source control layer of the target radio network controller 
indicates the radio link control layer to start the receiving 
window movement command in order to transmit the re- 
ceiving window movement command 
45 [0094] In the foregoing embodiments, the radio re- 
source control layer transfers the parameter or the data 
transferred from the original radio network controller to 
the radio link control layer Also, a value of a field of a 
length indicator of the unit data of a first radio link control 
so layer Including the radio resource control message 
transmitted from the target radio network controller to 
the terminal after the serving radio network sub-system 
relocation Indicates an information that the unit data of 
the corresponding radio link control includes the radio 
55 resource control message from a first portion thereof. 
[0095] In addition to these features, any one or more 
of the embodiments of the present invention may in- 
clude an initialization step for the radio link control layer, 
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where a status variable is initialized and a frame number 
is synchronized between the radio link control layer of 
the terminal add the radio link control layer of the target 
radio network controller. This will enable the terminal to 
successfully receive the radio resource control mes- 
sage before the target radio network controller transmits 
the radio resource control message corresponding to 
the serving radio network sub-system relocation to the 
terminal The target radio network controller may trans- 
mit an initial unit data to the radio link control layer of 
the terminal as a command performing an Initialization 
of the radio link control. 

£00961 Further, the radio resource control layer of the 
target radio network controller may transfer an initializa- 
tion start command to the radio link control layer in order 
that the radio link control layer of the target radio con- 
troller start In an initialization process of the radio link 
control layer. 

[0097] The radio link control layers of the target radio 
network controfler and the terminal are preferably set in 
order to allow the target radio network controller to suc- 
cessfully receive the corresponding radio resource con - 
trol message before the terminal transmits the radio re- 
source control message corresponding the serving ra- 
dio network sub-system relocation to the target radio 
network controller. Here, a frame number may be syn- 
chronized during setting of the radio link control layers 
of the target radio network controller and the terminal. 
A setting of the frame number may be transferred from 
an upper layer, and may be performed by increasing 
frame numbers used in the terminal and the target radio 
network controller by 1 (one) Alternatively, setting of the 
frame numbers used In the radio link control layer of the 
terminal and the radio link control layer of the target ra- 
dio network controller may be performed by increasing 
a larger value among an uplink frame number and a 
downlink frame number used in the radio link control lay- 
er of the terminal and the radio link control layer of the 
target radio network controller by 1 (one) based on the 
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[009B) The radio resource control layers of the termi- 
nal and the target radio network controller transmit re- 
spective command for a setting/resetting of correspond- 
ing radio link control layers 

[0009] A setting/resetting of a signaling radio bearer 
and a radio bearer in the terminal and the target radio 
network controller are performed after a process that the 
terminal transmits a response radio resource control 
message corresponding to the serving radio network 
sub-system relocation to the target radio network con- 
troller. Here, a frame number in the setting/resetting of 
the signaling radio bearer and the radio bearer between 
the terminal and the target radio network controller is 
set to a frame number initial value included In the re- 
sponse radio resource control message corresponding 
to the serving radio network sub-system relocation 
transmitted from the terminal to the target radio network 
controller.. The frame number Initial value included in the 
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radio resource control message may correspond to an 
initial value stored in a ciphering module of the terminal 
defined In a Universal Mobile Telecommunications Sys- 
tem standard of asynchronous IMT2000 system 
[Ot 00] Additional advantages, objects, and features 
of the invention will be set forth in part in the description 
which follows and in part, will become apparent to those 
having ordinary skill in the art upon examination of the 
following or may be learned from practice of the inven- 
tion. "The objects and advantages of the invention may 
be realized and attained as particularly pointed out in 
the appended claims 

BRIEF DESCRIPTION OF THE DRAWINGS 
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[0101] The invention will be described In detail with 
reference to the following drawings in which like refer- 
ence numerals refer to like elements wherein: 

Figure 1 shows a network architecture of a Univer- 
sal Mobile Telecommunications System (UMTS); 
Figure 2 shows a structure of a radio interface pro- 
tocol which may be implemented within the UMTS 
system; 

Figure 3 shows a structure of a Protocol Data Unit 
(PDU) used in a Radio Link Control (RLC) layer of 
the radio interface protocol of Figure 2; 
Figure 4 is an exemplary snapshot of the state of 
an AM RLC buffer; 

Figure 5 Is a diagram illustrating the concept of an 
SRNS Relocation procedure; 
Figure 6 is an SRNS Relocation signaling proce- 
dure In UMTS system; 

Figure 7 Is an SRNS Relocation signaling proce- 
dure of a related-art system which includes a UMTS 
Terrestrial Radio Access Network (UTRAN); 
Figure 8 shows a ciphering process performed in 
the radio interface protocol of Figure 2; 
Figure 9 is the structure of COUNT-C parameter 
used within RLC mode; 

Figure 10 is a flow diagram showing steps included 
In a series of embodiments of the method of the 
present invention identified as At and A2 for per- 
forming an SRNS relocation procedure; 
Figure 11 is a flow diagram showing steps included 
in a series of embodiments of the method of the 
present invention identified as 81 and 82 for per- 
forming an SRNS relocation procedure; 
Figure 12 is a flow diagram showing steps included 
in a series of embodiments of the method of the 
present invention identified as C1 > C2, and C3 for 
performing an SRNS relocation procedure; 
Figure 13 is a flow diagram showing steps included 
In an embodiment of the method of the present in- 
vention which performs SRNS relocation for the 
case of lossless radio bearers; and 
Figure 14 is a flow diagram showing steps included 
in an embodiment of the method of the present ln- 
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ventlon which performs SRNS relocation lor the 
case of seamless radio bearers. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

[01 021 The present Invention Is a system and method 
for performing an SRNS relocation procedure In a wire- 
less communications system The relocation procedure 
is performed m a manner which prevents an out-of-syn- 
chronizatlon condition from arising between transmitting 
and receiving entitles In one embodiment, the invention 
synchronizes ciphering information in the transmitting 
and receiving entities. By taking these steps, the present 
invention improves the reliability and efficiency of com- 
munications in the system. Whfle the Invention is suita- 
ble for use in a UMTS system, those skilled in the art 
can appreciate that the method may be performed in 
communications systems which adhere to other stand- 
ards and/or protocols. 

[0103] The method of the present invention controls 
the manner in which information Is transmitted between 
a receiver and transmitter, and Is especially well suited 
for use in the non-limiting application of where the trans- 
mitter is a UTRAN and the receiver is a user terminal 
(or user equipment as it Is called by the 3GPP initiative). 
When applied In this manner, the steps of the method 
may differ depending upon the type of SRNS relocation 
to be performed and the mode of operation of the RLC 
layers of the UTRAN and user terminal. 
[0104] The SRNS relocation procedure may be clas- 
sified into two cases In Case I SRNS relocation Is ini- 
tiated by the core or another network and the terminal 
is not informed that relocation is performed until the re- 
location procedure is terminated. Case f may therefore 
be characterized as corresponding to the situation 
where the terminal Is not involved in making the decision 
to perform relocation. In Case II, SRNS relocation Is in- 
itiated by the user terminal The terminal is therefore 
aware that relocation is being performed at the very star! 
of the procedure. Case if may therefore be character- 
ized as corresponding to the situation where the termi- 
nal Is involved in making the decision to perform SRNS 
relocation. 

[01 05] The various embodiments of the present in- 
vention melhod may be initially understood by distin- 
guishing them from the related-art method of Figure 7 
While the present invention may share some of the 
steps in the related-art method, the following discussion 
makes clear that the present Invention advantageously 
overcomes the synchronization and other problems that 
arise in this system A description of the related-art sys- 
tem will therefore be initially be provided 
[01 06} Referring to Figure 7, an initial step of the 
method differs depending upon whether the SRNS re- 
location procedure is requested by the network {Case I) 
or user terminal (Case if) in Case I, the method of the 
present invention begins when the network decides to 



perform SRNS relocation, i e , when the UTRAN de- 
cides to switch from one RNS (or a source RNC) to an- 
other RNS (or a target RNC) for purposes of communi- 
cation with the user terminal (Step 2) The network may 

5 decide to perform an SRNS relocation based on any one 
of a variety of factors For example, relocation may be 
desirable to reduce the amount of traffic being handled 
by the source RNC, to locate a shorter or more efficient 
communications path for purposes of handling a cell 

io with the user terminal, or other reasons which may be 
understood by those skilled in the art 
[01 07] In Case II, the method of the present invention 
begins when the user terminal transmits an RRC mes- 
sage In the form of a CeH/URA Update message to the 

is source RNC. (Step 1). This message includes a request 
for changing the SRNS of the UTRAN Such a message 
maybe transmitted, for example, when the user terminal 
moves to a new cell within the wireless system, e g , 
when a handoif operation is imminent or required At this 

20 time, the network may decide whether to favorably re- 
spond by satisfying the request or may immediately re- 
spond . 

[01 08} The second through fifth steps are commonly 
performed for Cases I and H In the second step, refo- 

25 cation preparation is performed (Step 3) This involves 
forwarding relevant parameters for communicating with 
the user terminal from the source RNC to the target RNC 
through an RRC information container This container 
Includes, for example, ciphering information {e g , 

30 downlink HFN and uplink HFN parameters) for signaling 
radio bearers, as well as radio resources including new 
RABs for purposes of changing the serving RNS from 
the source RNC to the target RNC. The type of radio 
bearers reserved in this step depends on whether AM 

35 or UWi RLC mode is being supported In the UTRAN. If 
AM mode is supported, one or more lossless radio bear- 
ers are reserved so that lossless SRNS relocation may 
be performed. If UM mode is supported, one or more 
seamless radio bearers are reserved so that seamless 

*0 caniNO leiuucsiiuii may u« pcnwHiicO 

[01 09 J The third step includes receiving an RANAP 
Relocation Command from the core network, and more 
specifically from an existing SGSN In the core network 
(Step 4) The existing SGSN may be referred to as the 

45 "old SGSN," and if relocation results in requiring a 
change of SGSNs (which may not always be the case) 
a "new SGSN" will bo assigned after relocation The Re- 
location Command informs the source RNC of the RABs 
to be released and the RABs that are subject to data 

so forwarding in connection with the relocation procedure 
Lossless SRNC (performed for AM RLC operation) may 
be configured for RABs subject to data forwarding The 
PDCP layer supports PDCP sequence numbering when 
lossless SRNS relocation is supported. 

55 [0110] The fourth step includes transmitting a Relo- 
cation Commit message from the source RNC to the tar- 
get RNC, (Step 5) In this step, for the affected radio 
bearers, the source RLC is stopped and the PDCP 
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transmission sequence numbers are retrieved by the 
rrC- The PDCP of the source RNC transfers the se- 
quence numbers and other Information tor communicat- 
ing with the user terminal lo the target RNC 
[0111] The fifth step Includes transmitting an RANAP 
Relocation Detect message from the target RNC to the 
source RNC (Step 6) When this message is received, 
the target RNC becomes the serving RNC A corre- 
sponding change from the old SGSN to the new SGSN 
may be performed at this time After these steps, the 
relocation has occurred 

(0112] The sixth slep includes transmitting an RRC 
message from the target RNC io the user terminal, and 
more specifically to the RRC layer of the user terminal 
in Case I, the RRC message is in the form of a UTRAN 
Mobility information message, in Case II, the RRC mes- 
sage is in the form of a Cetl/URA Update Confirm mes- 
sage In each of these messages, a new U-RNTI is in- 
cluded to inform the user terminal that an SRNS reloca- 
tion procedure was performed. 
[0113] A seventh step includes calculating a START 
value In the user terminal In response to downlink coun- 
ter synchronization information The START value is 
then transmitted from the user terminal to the RRC layer 
of the target RNC In an RRC message called a UTRAN 
Mobility Information Confirm message (Step 7) 
[01141 An eighth step Includes establishing RLC en- 
tities in the target RNC based on the START value in* 
eluded In the UTRAN Mobility Information Confirm mes- 
sage In the meantime, the user terminal may also re- 
establish Its RLC entities with the transmitted START 
value (Step 8) 

[0115] The foregoing description may serve as a 
framework for the approach taken by the method of the 
present invention for overcoming the out-of-synchroni- 
zatbn problem that adversely affects the performance 
of the related- art method of Figure 7. This problem oc- 
curs in the sixth step discussed above. 
[0116] in this step, the target RNC transmits an RRC 
message either on SRB1 or SRB2 depending upon the 
case and the mode of operation of the RLC entities,. 
More specifically, either a UTRAN Mobility Information 
message is sent on an AM/DCCH (SRB2) or UM/DCCH 
(SRB1 ), or a Cell URA Update Confirm message is sent 
on UM/DCCH {SRB1) Although the Cell/URA Update 
Confirm message can use UM/CCCH (SRBO), SRNS 
relocation policy (if SRNS is relocated before the Ceil/ 
URA Update confirmation is sent, a DCCH should be 
used to allow ciphering of the message contents) may 
require that this message should not use SRBO In case 
of SRNS relocation 

[0117] When the steps shown in Figure 7 are per- 
formed, out-of-synchronization problems arise between 
the user terminal and UTRAN which prevent communi- 
cations from being performed Some of these problems 
occurs as follows 

[01181 Problem 1 ; CL RRC Message Is Sent on SRB1 
(UM/DCCH) Before SRNS relocation, the source RNC 



may be communicating PDUs with the user terminal 
based on synchronized deciphering information. For ex- 
ample, the source RNC may transmit PDUs based on a 
downlink HFN parameter ^ X and a transmission se« 

s quence number corresponding to a state variable VT 
(US) = 50 for UNA mode of operation Similarly, the user 
terminal may transmit PDUs based on an uplink HFN = 
X and a VR(US) = 50. Because the deciphering infor- 
mation and transmission sequence numbers are syn- 

10 chronized, the user terminal and source RNC can com- 
municate without problems However, when SRNS re- 
location occurs, since the HFN value is transferred from 
the source to the target RNC without any additional in- 
formation (e.g., without transmission sequence number 

is information in the form of one orrnore of state variables 
VT{US) or VR{US))> the target RNC establishes a UM 
RLC entity with the same deciphering information used 
by the source RNC (i e. , DL HFN - X) but with state var- 
iable VT(US) set to a newly initialized value, e g., zero- 

20 [0119} Accordingly, when the target RNC sends an 
RRC message to the user terminal, the user terminal 
wtli in most cases recognize the transmission sequence 
number in the RRC message as corresponding to an 
out-of-sequence number, because it does not include 

25 the sequence number that follows the fast PDU trans- 
mitted by the source RNC. When this occurs {e g , when 
the user terminal detects that the received RRC mes- 
sage has a serial number SN = 0), it will conclude that 
a new PDU has been received and more specifically that 

30 PDUs having serial numbers of between 50 and 127 are 
missing. As a result, the user terminal will increase its 
HFN to a value of X + 1 for purposes of deciphering fu- 
ture PDUs However, the target RNC will continue to 
transmit PDUs based on HFN = X Because there is a 

35 discrepancy in the deciphering information used by the 
user terminal and target RNC, the user terminal will not 
be able to decipher and thus successfully receive the 
PDUs transmitted from the target RNC. This means that 
the user terminal cannot receive the RRC message. 

40 

Problem 2: DL RRC Message is Sent on SRB2 (AM/ 

T^1 U,'..A,.- J— - -~^r ^*^»**#V<*+>**tot*m^^^ _.,,. > ^ - . ...^. ^» . W .^ ^ ,^>,,^ W ^ ^W^^^*»^>^^^»«^«■ 

DCCH) 

[01 20] Before SRNS relocation, assume that DL HFN 
45 = X and VT(S) = 3000 in the source RNC and DL HFN 
« X and VR(R) ~ 3000 in the user terminal Because the 
deciphering information and transmission sequence 
numbers are synchronized, the user terminal and 
source RNC can successfully communicate However, 
so when SRNS relocation occurs, since the HFN value is 
transferred from the source RNC to the target RNC with- 
out VT(S) indicative of transmission sequence number, 
the target RNC will establish an AM RLC entity with DL 
HFN = X but with VT(S) set to an Initial value, e g.. VT 

55 (S) - 0. 

[0121] When the RRC message is sent from the target 
RNC to the user terminal, the user terminal will discard 
the message if its transmission sequence number 
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(which Is zero in this case) lies outside of the range of 
the receiving window However, even if the sequence 
number of the RRC message lies within the receiving 
window, the user terminal will consider it to be a new 
PDU, i.e.. that PDUs having sequence numbers from 
3000-4095 are missing When this occurs, the user ter- 
minal sets its HFN - X 4- 1 As a result, the deciphering 
Information in the user terminal and target RNC are dif- 
ferent and therefore the user terminal will not be able to 
receive the RRC message transmitted from the larger 
RNC 

[0122] in both problems discussed above (SRS1 or 
SRB2), the user terminal In most cases cannot receive 
the RRC message transmitted from the target RNC As 
a result, SRNS relocation fails, Of course, it Is noted that 
mere is a slim possibility that the user terminal will be 
able to receive the Initial RRC message from the target 
RNC r but this can only happen when VT(US) * VR(US) 
= Oor VT(S) - VR(R} = 0- However, even if the Initial 
RRC message from the target RNC is successfully re- 
ceived and deciphered by the user terminal, the targe! 
RNC will not be able to receive the UTAN Mobility infor- 
mation Confirm RRC message transmitted from the us- 
er terminal This message is sent on AM/DCCH (SRB2), 
and it cannot be received by the target RNC because 
VT(S) ~ 3000 in the user terminal but VR(R) « 0 in the 
target RNC. 

[01 23] The system and method of the present Inven- 
tion overcomes these and other problems that arise in 
the related-art system as a result of synchronization and 
transmission sequence number mis-matches As the 
following embodiments will reflect, the target RNC and 
user terminal will be controlled to synchronize all infor- 
mation required in order for a successful relocation pro- 
cedure to be performed. The specific embodiments will 
now be discussed. 

[0124] The method of the present Invention may be 
performed differently depending upon whether Case I 
or Case II applies When SRNS relocation Is requested 
by the network (Case I), the sixth step Includes synchro- 
nizing ciphering information In the target RNC to cipher- 
ing information that is expected to be used in the user 
terminal. This synchronisation may be performed in 
view of the following realization 

[0125] During the relocation procedure, RLC PDUs 
transmitted from the target RNC to the user terminal will 
have initialized values For example, the first PDU trans- 
mitted will be given an initial transmission sequence 
number such as zero On the user terminal side, the 
RLC layer receives PDUs and orders them based on 
transmission sequence number Since the user terminal 
was communicating with the source RNC prior to relo- 
cation, the next PDU the RLC of the user terminal will 
expect to receive is one whose transmission sequence 
number consecutively follows the transmission se- 
quence number of the last-received PDU The first PDU 
transmitted from the target RNC in the UTRAN. howev- 
er, will have an Initialized sequence number and thus in 



all probability will not correspond to the expected 
number. 

£0128] When this occurs once or a predetermined 
number of times, the user terminal RLC will conclude 

5 that a wrap-around condition has occurred When such 
a condition is detected, the RLC of the user terminal will 
adjust its deciphering Information by changing Its HFN 
parameter to a new value Tills change may involve in- 
crementing the HFN parameter by 1 

10 [0127] In the related-arl method of Figure 7, the target 
RNC did not compensate for this change in deciphering 
Information in the user terminal Instead. PDUs were ci- 
phered using ciphering information (i e ., the HFN pa- 
rameter) included in the RRC information container sent 

15 from the source RNC to the target RNC. As a result, 
PDUs transmitted from the target RNC could not be de- 
ciphered by the user terminal and a stall in communica- 
tions occurred. 

[01 28] The present invention overcomes this problem 

20 by taking one of several approaches On approach in- 
volves adjusting ciphering Information in the target RNC 
received from the source RNC. This adjustment ensures 
that the target RNC ciphers PDUs with the same HFN 
parameter the user terminal will use during deciphering 

25 Since UT RAN management software Is programmed to 
know how the user terminal will adjust its HFN parame- 
ter when a PDU having an out-of-sequence transmis- 
sion sequence number Is received, the target RNC may 
cipher the PDUs to be sent to the user terminal using 

30 the same adjusted HFN parameter. The nature of the 
adjustment performed by the present invention depends 
on whether Case I or II is being observed and whether 
the RLCs of the user terminal and target RNCs are op- 
erating In AM or UM mode. The following situations ap- 

3S ply. 

A . Downlink RRC Message Sent on SRBt (UM/DCCH)- 

[0129] In this case, the RLCs of the target RNC and 
40 user terminal are operating In UM mode.. The target 
RNC sends an RRC message on a serving radio bearer 
SRB1 (which corresponds to a UM DCCH channel) to 
the user terminal The following situations apply. 

as A 1 Target RNC Establishes SRB1 and Incre ments PL 

*tH i n i H i n I n II m d wwm ww m m i i rf ff Wf J ' VH I H i U III Wt wiWmntM p OH ' * ' --.-urn— it ■■ . m ... .j. _ t : ~ Jti rm7r™""™ 

HFN 



[01 30] Referring to Figure 10, the target RNC re- 
ceives an RRC information container from the source 

so RNC The container includes ciphering information 
which preferably includes an HFN parameter which the 
source RNC was using to communicate with the user 
terminal. When the RRC information container is re- 
ceived, the target RNC increments the HFN parameter 

55 and establishes a new SRB1 Because the target RNC 
has foreknowledge of the way In which the user terminal 
changes its HFN parameter when a wrap-around con- 
dition occurs or when an out-of-sequence PDU is re- 
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celvad, the targe! RNC increments its HFN parameter 
in an Identical manner. As a result, the PDUs generated 
by the target RNC will be ciphered in a way which is 
decipherable by the user terminal. 
[0131] Once the PDUs have been generated, they are 
transmitted from a UM RLC of the target RNC to the user 
terminal The first PDU transmitted includes an initial 
transmission sequence number, e g , SN = 0- When the 
user terminal receives the PDUs, the user terminal de- 
tects that the first PDU has an out-of-sequence trans- 
mission sequence number The user terminal may per- 
form this detection function by extracting state variable 
VR(US) from the first PDU Since this state variable pro- 
vides an indication oi the transmission sequence 
number that corresponds to this PDU, a wrap-around or 
out-of-sequence condition may be detected For exam- 
ple, in the case where VR(US) has values from 0 to 127, 
the user terminal may determine that PDUs having the 
value of the VR(US) in the received PDU to VR number 
127 are missing 

[0132J When this condition is detected, the user ter- 
minal will adjust its HFN parameter, For example, by in- 
crementing this parameter by 1 Since the PDUs trans- 
mitted from the target RNC were generated and trans- 
mitted in accordance with this same H FN parameter, the 
PDUs may be deciphered and communications may 
take place in spite of the relocation procedure By syn- 
chronizing the ciphering information in the user terminal 
and target RNC, the present Invention advantageously 
overcomes the out-of -synchronization problem that oc- 
curs In the related-art system of Figure 7. 
[01 33 J An optional but desirable step Involves Includ- 
ing a data start Indicator (which may be referred to as 
Special L1) in one or more PDUs transmitted from the 
target RNC to the user terminal In accordance with the 
present invention, the data start Indicator may be Incor- 
porated into the PDUs transmitted by the target RNC 
over a UM DCCH channel The inclusion of this indicator 
Is advantageous. For example, if the user terminal re- 
ceives a PDU from the target RNC without the data start 
Indicator, the user terminal may consider the PDU to be 
part of a previous SDU and may just discard it When 
received by the user terminal, the data start indicator will 
be interpreted to Indicate that the PDU to which it is at- 
tached is not part of a previous SDU Including this in- 
dicator will therefore ensure that PDUs received from 
the target RNC will not be discarded. In order to maxi- 
mize transmission efficiency, the first PDU transmitted 
from the target RNC (i e , the PDU having a transmis- 
sion sequence number SN - 0) preferably includes the 
Special L1 indicator 

A 3. Source RNC Transfers VT( UB) to Target R NC 

[0134] This approach differs from the approach in A. 
1 in that instead of incrementing its HFN parameter, the 
first PDU transmitted from the target RNC to the user 
terminal contains the next transmission sequence 



number which the user terminal expects to receive 
Thus, the HFN parameter used by the target RNC and 
user terminal remains synchronized and therefore data 
communications may be performed. A more detailed de~ 

5 scription of this approach wit! now be provided 

[0135) In an Initial step, the source RNC delivers an 
RRC Information container 50 that includes stale varia - 
ble VT{US) of serving radio bearer SRB1 to the target 
RNC , State variable VT(US) Is indicative of a transmts- 

10 sion sequence number related to the transmission se- 
quence number of the last or one of the last PDUs trans- 
mitted from the source RNC to the user terminal The 
target RNC uses state variable VT(US) as a basis for 
transmitting its first PDU 60 to the user terminal For ex- 

15 ample, if VT{US) corresponds to the last sequence 
number transmitted, the target RNC may increment the 
transmission sequence number corresponding to VT 
(US) by one and then transmit the first PDU containing 
this value . When the user terminal receives this PDU, it 

so will detect that this PDU is has the next-in-sequence 
number that It expected and thus no wrap-around or 
missing PDU condition will be detected As a result, the 
user terminal will not increment its HFN value as In the 
previous case; and because the PDU was ciphered 

25 based on the same HFN value, the user terminal will be 
able to decipher it 

[0136] As an alternative to this approach, the VT(US) 
variable delivered from the source RNC to the target 
RNC may be the next-in-sequence number which the 
30 user equipment expects to receive In this case, the tar- 
get RNC writ transmit the first PDU with the number cor- 
responding to VT(US). 

{0137] This approach may include a number of addi- 
tional steps First, a new IE (Information element) may 
35 be used in light of the addition of VT(US) of SRBt into 
the RRC Information container 

[01 38] Second, the RLC establishment step may be 
modified For example, when the RLC entity is estab- 
lished, all the state variables may be set to initial values 

40 ( e g , 0). As a result, it may not be possible to establish 
the UM RLC entity with VT(US) other than 0 In order to 
compensate for setting the state variables to initial val- 
ues, an establish and modify procedure should be per- 
formed. That is, at first, RLC entity Is established with 

45 all the state variables to be 0, at second, the state var- 
iables are modified to be desired values 
[01 39 J Third, a data start indicator (e.g.., Start LI) 
should be included in the first UM PDU transmitted from 
the target RNC to the user terminal If the first PDU is 

so transmitted without this Indicator and if, for example, the 
PDU with sequence numberSN = VT(US) - 1 is lost, the 
user equipment will discard the PDU. Because the user 
equipment considers that the PDU contains incomplete 
SDU a portion of which may be contained In the former 

55 PDU . Including the data start indicator In the first PDU 
transmitted from the target RNC will therefore guarantee 
that the RRC message will be received by the user ter- 
minal 
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B Downlink RRC M essag^entgn SRB2 (AMg>CCH)_. 

[0140] In mis case, the BLCs of the target RNC and 
userterminal are operating in AM mode.. The target RNC 
sends an RRC message on a serving radio bearer SR82 
(which corresponds to an AM DCCH channel) to the us- 
er terminal 

B 1 Target RNC Establishes SRB2 and Initializes RLC 
RESET Procedure, 

[0141] Referring to Figure 11, before sending the 
RRC message, the target RNC performs an RLC RE - 
SET operation which involves resetting the transmission 
sequence number and state variables to initial values 
Preferably at the same time, the target RNC transmits 
a Reset PDU 70 to the user terminal According to one 
aspect of the Invention, the Reset PDU is transmitted 
without being ciphered and has no transmission se- 
quence number Consequently, the user terminal will be 
able to receive the Reset PDU transmitted through 
SRB2 Upon receiving the Reset PDU t the user terminal 
will reset its state variables and transmission sequence 
number to the same miliar values set In the target RNC. 
[01 42 J Because the Reset PDU has no transmission 
sequence number, the user terminal will not detect a 
wrap-around or out-of-sequence condition when the Re- 
set PDU \b received. Therefore, the HFN parameter In 
the user terminal will not be Incremented. As a result, 
the HFN parameter which the target RNC received from 
the source RNC and the HFN parameter of the user ter- 
minal will be the same And, since the state variables 
and transmission sequence numbers of the target RNC 
and user terminal have been initialized to like values, 
the target RNC and userterminal may successfully com- 
munication with one another When reset Is completed 
in the user terminal, a reset acknowledgment message 
Reset ACK PDU B0 will be transmitted from the user 
terminal to the target RNC 

[0143] As an alternative to this embodiment, the Re- 
set operation performed in the target RNC may cause 
the HFN parameter to be incremented- The Reset PDU 
may then be modified so that the user terminal incre- 
ments its HFN value upon receipt This may be accom- 
plished, for example, by transmitting the Reset PDUwith 
an initial or out-of-sequence transmission sequence 
number 

[0144] As a result of the foregoing steps, the HFN pa- 
rameters and transmission sequence numbers of the 
target RNC and user terminal will be synchronized In 
order to achieve this synchronization, it Is preferable but 
not necessary to provide a new trigger for the RLC Reset 
procedure, More specifically* under norma* operating 
conditions an RLC Reset procedure is performed when 
an RLC protocol error is detected and/or when one of 
three trigger conditions specified in theSGPP specifica- 
tion Is detected In this embodiment of the present In- 
vention, the Reset procedure may be performed when 



a fourth trigger condition is detected . Referring to the 
specification, RLC reset procedure is performed, if one 
of the following triggers Is detected 

s 1) "No^Discard after MaxDAT number of retrans- 
missions' 1 is configured and VT{DAT) equals the 
value MaxDAT; 

2) VT(MRW) equals the value MaxMRW; 

3) A STATUS PDU including "erroneous Sequence 
to Number" is received; 

[01 45] More specifically, in accordance with an alter- 
native embodiment of the present invention, a new C- 
primitive (a control message from RRC to RLC) and a 
15 new trigger in RLC protocol is used for initiating the Re- 
set procedure 

[0146] During the Reset procedure, at least one addi- 
tional step may be performed . In this step, all RLC SDUs 
In the user terminal and the target RNC are flushed 
20 Though this embodiment of the invention requires some 
time to perform and may suffer some loss of data, it pro- 
vides a clear solution to the problem of unsynchrontzed 
ciphering passwords realized by the related-art system. 

25 b 2, Source RNC Transfers VT{S) to Target RNC 

101 47] Referring again to Figure 1 1 , this embodiment 
of the invention Is similar to the embodiment discussed 
In A.2 above, except that a different approach is taken 
30 to account for the receiving window In the userterminal 
and the fact that RLC PDUs are re-transmitted in the AM 
operational mode 

Accordingly, other than adjusting the sequence number 
of the RLC PDU to be transmitted to the terminal and 

35 synchronizing the HFN value, the target RNC may be 
required to consider data units previously transmitted to 
the terminal by the source RNC which were not con- 
firmed by the userterminal The following steps may be 
taken to compensate for this prospective problem. 

40 [0148] In process step B 2 1 t the source RNC trans- 
fers a message 90 containing information related to the 
setting of the SRB2 to the target RNC. This information 
includes the sequence number, state variable VT{S), 
and the HFN parameter used by the RLC layer of the 

45 source RNC, together with one or more RLC PDUs or 
an RRC message that is being re-transmitted In proc- 
ess step B 2 2 , the target RNC then transmits one or 
more PDUs 100 to be re-transmitted to the user terminal 
using the Information transferred from the source RNC 

so As a result, the target RNC will transmit the PDUs in the 
same manner and with the same information as the 
source RNC. 

[01 49} As an example, consider the case where the 
source RNC transmits Its HFN parameter, one or more 
55 RLC PDUs (o be re -t ransmitted, VT(S) indicating se- 
quence number, and VT(A) In step 81 of Figure 1 1 The 
target RNC stores the PDUs from the source RNC after 
configures the RLC layer with the received parameters 
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(Step B 2 2 In Figure 11), and sends a UTRAN Mobility 
Information Message with a new PDU starling with the 
sequence number corresponding to VT(S) Because the 
target RNC can transmit data while sustaining a re- 
transmission buffer state of the SRB2 equal to the re- 
transmission buffer slate of the source RNC, the user 
terminal can recover the re transmitted data from the 
target RNC through the SRB2 channel 
[0150] In accordance with another embodiment, the 
source RNC delivers VT{3) to the target RNC through 
an RRC Information container The target RNC then es- 
tablishes SRB2 (AM RLC) with the transferred values 
and sends an BBC message to the user terminal with 
those values. The user terminal operates in a different 
manner compared with A 2 because the AM RLC of the 
terminal receives PDUs that only lie within a valid range 
of a receiving window 

[01 51 1 If the transmission sequence number corre- 
sponding to variable VT{3) is equal to VR(R), no prob- 
lem occurs But if vT(S) is larger than VR(R) {mainly 
due to the unconfirmed RLC SDLfs in the source RLC), 
the user terminal will transmit a status PDU to the target 
RNC indicating that AMD PDUs from VR(R) to VT(S)-1 
are missing, If appropriate action is not taken, the fol- 
lowing problem may occur: Since VT(A) - VT(S), the 
target RLC finds that the received status PDU contains 
an "erroneous Sequence Number and it will initiate a 
Reset procedure The RLC PDUs transmitted before the 
Reset procedure is implemented will be lost (note thai 
the RLC buffers may be flushed during the Reset pro- 
cedure) 

[01 52] To guarantee successful transmission, this 
embodiment of the present Invention delivers VT(A) in 
addition to VT(S) from the source RNC to the target 
RNC The target RNC then transmits PDUs in SRS2 
based on VT(A), VT(S) and the HFN parameter trans- 
ferred from the source RNC An establish and modify 
procedure may then be performed as discussed in con- 
nection with the A,2 embodiment of the Invention. 
[01 53 J The RRC message is transmitted by the AMD 
PDUs from VT(S) If a status PDU indicating that the 
user terminal did not receive the PDUs from VR(R) to 
VT(S)-t is transmitted from the terminal to the target 
RNC, the target RNC transmits an MflWSUFI message 
to the userterminai in order to move the receiver window 
to VT(S) In order to implement these features, an addi- 
tional trigger for transmitting the MRW SUFI message 
may be used Consequently, a new C«primitive may be 
implemented along with a new trigger for performing an 
SOU discard with explicit signaling procure. 
[0154J In accordance with an alternative embodiment, 
the source RNC delivers its HFN value and VT(S) to the 
target RNC (Step B.2 1 in Figure 11 ), and stops trans- 
mitting PDUs to the user terminal prior to SRNS reloca- 
tion. In the RLC of the terminal, the processing of pre- 
vious RRC messages is completed. Therefore, the first 
PDU received after SRNS relocation includes the 
UTRAN Mobility Information message having the VT(S) 



value. 

[0155J In accordance with another embodiment, the 
source RNC delivers its HFN vaiue and VT(S) to the tar- 
get RNC (process 8 2.1 in Figure 11) The source RNC 

5 then transmits a command to the user terminal to in- 
struct the RLC layer of the user terminal to move its re- 
ceiving window and to not request re -trans mission data 
The RRC layer of the UTRAN may be used to instruct 
the RLC layer of the source RNC to transmit this com- 

to mand Remaining steps of the method are similar to the 
embodiment discussed Immediately above, however 
this embodiment may be implemented to remove RRC 
messages before the SRNS is relocated and for solving 
the re-transmission problem 

15 [0156] In any one or more of the 3 2 embodiments 
discussed above, an optional step of including a data 
start Indicator in the first PDU transmitted by the target 
RNC to the user terminal may be performed- The data 
start Indicator may be the same type transmitted in the 

so RRC message transmit! ed from the target RNC though 
SRB1 In accordance with the embodiment previously 
discussed 

[01 57] The following example applies: the RLC PDU 
corresponding to the sequence number of VT(S)-1 may 
25 not be correctly received The next RLC PDU transmit- 
ted by the target RNC right after the relocation proce- 
dure is performed may include the data start Indicator 

B 3 Do Not Send UTRAN Mobility information on SRB2 
so in Case of SRNS 

[0158] Relocation From embodiments B 1 and B 2. t 
It is clear that the transmission of an RRC message on 
SRB2 may be problematic In some respects, in this 8 
$5 3 embodiment, embodiment A 1 or A.2 may be Imple- 
mented without the transmission of UTRAN Mobility In- 
formation on SRB2- 

[0159] The embodiments discussed above are all 
preferably performed before or during transmission of 

40 UTRAN Mobility Information (Case I) or a Cell/URA Up- 
date Confirm message (Case II). That is, either type of 
message can be received by the user terminal when the 
A and B embodiments of the Invention are performed. 
Even though the user terminal may receive downlink 

45 rrc messages correctly from the UTRAN, certain sit- 
uations may arise which writ prevent the target RNC 
from receiving a UTRAN Mobility Information Confirm 
massage from the user terminal in both Cases I and II. 
This confirmation message may be sent in SR82 (AM/ 

so QCCH), but because the VT(S) in the user terminal and 
the VR(R) In the target RNC are usually different (e g , 
VT(S) * 0> VR(R) a 0) a need may arise to synchronize 
the HFN and SN values in the user terminal and target 
RNC before the UTRAN Mobility Information Confirm 

55 message is transmitted . The following embodiments of 
the present invention address this problem 



17 



33 



EP 1 337 125 A2 



34 



C 1 . User Terminal Receives D ownlink RRC Message 
on SRB1 (UM/CCCH) 

[0160] Referring to Figure 12, in this case only the 
downlink HFN of SRB1 is synchronized Before trans- 
mission of an uplink RRC message (la , an RRC mes- 
sage from the terminal to the target RNC), both the tar- 
get RMC and the user terminal should perform opera- 
tions 110 and 120 which respectively establish and re- 
establish SRB2- This includes setting both the target 
RNC and user terminal to the same HFN value. These 
steps may be accomplished by ciphering a message 
transmitted from the user terminal to the target RNC with 
an incremented HFN value (e g, the current value of 
HFN + 1) as is performed In the case of a combined 
Hard Handover and SRNS relocation Another possible 
value for HFN Is MAX(UL HFN of SR82 I DL HFN of 
SRB2) + 1 Any value can be used as long as the user 
terminal and target RNC have the same HFN 

C 2. User Terminal Receives Downlink RRC Message 
on SRB2 (AM/DC CH ) with a RESET Procedure. 

[0161 J If the user terminal receives a downlink RRC 
message on SRB2 and the embodiment of B-t is per- 
formed, SRB2 does not have to be established/re-es- 
tablished after the message is received During the Re- 
set procedure, the HFN values In the user terminal and 
target RNC (UL and DL HFNs) are synchronized and 
the usertermlnal sends an UL RRC message to the tar- 
get RRC without re-establishing SRB2 After transmis - 
sion of the UL RRC message, both the usertermlnal and 
the UTRAN should estabffeh/re-establfsh the SRBs (ex- 
cept SRB2) and RBs with the START value included In 
the UTRAN Mobility information Confirm message 

C.3 User Terminal Receives Downlink RRC massage 
on SRB2 (AWDCCH) with an SPU Discard with Explicit 
Signaling Procedure. 

[0162] if the user terminal receives a DL RRC mes- 
sage on SRB2 and the embodiment of B 2 is performed, 
only the DL HFN of SRB2 is synchronized Since the UL 
HFN is not synchronized, SR82 must be established/re- 
established in both the user terminal and the UTRAN 
The rest of the procedure is the same as in C.1 except 
that DL SRB1 needs to be re-established 
[0163] in one or more of the C embodiments dis- 
cussed above, after transmission of the UL RRC mes- 
sage, both the user terminal and the UTRAN may re- 
establish/establish the SRBs (except SRBS) and RBs 
with a START value which corresponds to an Initial value 
of the HFN This may be accomplished by transmitting 
The START value In the RRC message, I e , the UTRAN 
Mobility Information Confirm message As an example, 
the START value may be stored in the upper 20 bits of 
the HFN If the size of the HFN exceeds 20 bits, the re- 
maining bits may be initialized to 0 The START value 



may correspond to a predetermined value (which may, 
lor example, be defined in accordance with the stand- 
ards developed by the 3GPP) and may be managed by 
a ciphering rnodute of the terminal. The START value 
$ may be disconnected from the terminal or may be up- 
dated according to a change in the HFN value during 
connection 

[0164] It should be noted that the embodiment of C. 
1 may be applied for all cases. Though the usertermlnal 

w receives a DL RRC message on SRB2 with a Reset Pro- 
cedure in C 2, the re-establlshment of SRB2 does not 
create problems in normal operation.. In this case, the 
HFNs may be updated a maximum of two times 
[0165] In the foregoing embodiments, it may be pref- 

is erable not to include an IE (Information element) "RLC 
re-establishment indicator (RB2, RBS, and RB4)* in the 
Cell Update Confirm message. If it is included, the user 
terminal may re-establish SRB2, SRB3, and SRB 4 and 
set their HFN values to a START value included in the 

20 latest transmitted Cell Update message. Since the user 
terminal SRB2 is re-established with this START value, 
the UTRAN may not be able to receive a UTRAN Mo- 
bility Information Confirm message (UTRAN SRB2 is 
established with either H FN* 1 or MAX(ULHFN of SRB2 

25 \ DL HFN of SRB2) + 1) It Is further noted that these 
embodiments may correspond to all of the SRBs and 
common RBs. However, for SRB2. because the HFN 
value Is synchronized before the UTRAN Mobility Infor- 
mation Confirm message Is transmitted, it may not be 

ao necessary to reset the HFN vafue Also, while the initial 
value for VT(US) has been illustratively discussed as 
corresponding to zero, those skilled in the art can ap- 
preciate that other initial values may be used for this or 
any other state variable discussed herein. 

35 [0166] The embodiments of the present invention 
have been adopted in the following 3GPP Technical 
Specifications which are incorporated by reference 
herein: Technical Specification TS 25 303 v310 0, 
Technical Specification TS 25 303 v3 11.0, Technical 

40 Specification TS 25 322 v3 9 0, Technical Specification 
TS 25 331 v3 9 0, Technical Specification TS 25 331 
v3.10 0, and ail updates, revisions, and modification 
thereto . 

[01 87] A re-statement of various embodiments of the 
45 Invention as indicated above may be provided as fol- 
lows 

Combined CeWURA Update and SRNS Relocation 
(Lossless Radio Bearers) 

50 

[0168] The method of the present invention may be 
initiated by the source RNC deciding to perform an 
SRNS relocation Steps of Shis method, which have 
been previously discussed and are re-stated below, are 
55 shown in greater detail In Fig, 13 Here, Case 1 repre- 
sents the situation where the user equipment (UE) is not 
involved and Case 2 represents the situation wherein 
the UE Is involved and a Combined Cell/URA update 
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and SRNS relocation Is performed 
[0169] In an initial step, an RANAP Relocation Com- 
mand is received by the source RNC from the CN, indi - 
cating the RABs to be released and the RABs that are 
subject to data forwarding Lossless SRNS relocation 
may be configured for RABs that are subject to data for- 
warding. The PDCP layer supports PDCP sequence 
numbering when lossless SRNS relocation is support- 
ed 

[0170] For the affected radio bearers, the RLC entity 
is stopped and the PDCP sequence numbers are re- 
trieved by the RRC The PDCP send and receive se- 
quence numbers are then transferred in the RNSAP Re- 
location Commit message from the source to the target 
RNC for RABs that support lossless SRNS relocation 
The target RNC becomes the serving RNC when the 
RANAP Relocation Detect message is sent 
[0171] The target RNC then sends a UT RAN MOBIL- 
ITY INFORMATION (Case 1 ) message on SRB#1 (UM/ 
DCCH) or SRB#2 (AM/DCCH), or a CELL/URA UP- 
DATE CONFIRM message (Case 2} on SRB81 (UM/ 
DCCH), which configures the UE with the new U-RNTI 
and indicates the uplink receive PDCP sequence 
number for each radio bearer configured to support loss- 
less SRNS relocation 

[0172J If SRB#1 is to be used, the target RNC estab- 
lishes the UM RLC entity for SRB#1 and the DL HFN 
and/or the VT(US) values are set to the values In the 
RRC container In performing this step, the DL HFN val- 
ue may be set to the current DL HFN value incremented 
by one In the UM RLC entity a "Special LI" Is preferably 
used to Indicate that an RLC SOU begins in the begin- 
ning of an RLC PDU 

[0173] Sf SRB#2 is to be used, the target RNC estab - 
lishes the AM RLC entity and the DL and UL HFN values 
are sel to the current DL and UL HFN values Before 
sending a Iff RAN MOBILITY INFORMATION mes- 
sage, the transmitting side of the AM RLC entity initiates 
RLC RESET procedure to synchronize the HFN values 
between the UTRAN and UE 

[0174] Upon reception by the UE of the message, the 
UE compares the uplink receive PDCP sequence 
number with the UE uplink send PDCP sequence 
number If this confirms that PDCP SDUs were success- 
fully transferred before the start of relocation (i e , al- 
ready received by the source RNC), then these are dis- 
carded by the UE The UE re-initializes the PDCP head- 
er compression entities of the radio bearers configured 
to use a header compression protocol The RLC (eg,, 
AM RLC} entity for SR8ff2 Is (re-established both on 
the UTRAN and UE sides, and their HFN values are set 
to VALUE incremented by one (Here, VALUE may be 
defined as either the current HFN value or 

[01 75] If the UE has successfully configured itself, it 



shall send a UTRAN MOBILITY INFORMATION CON- 
FIRM message (Case 1 and Case 2) These messages 
preferably contain the START values and the downlink 
receive PDCP sequence number for each radio bearer 

5 configured to support lossless SRNS relocation 

[0176] Upon reception and acknowledgment by the 
UTRAN of the message, the UTRAN compares the 
downlink receive PDCP sequence number with the 
downlink send PDCP sequence number The UTRAN 

10 initializes the PDCP header compression entities of the 
radio bearers configured to use a header compression 
protocol The RLC entities for affected radio bearers 
(other than SRB#2) are (reestablished both on the 
UTRAN and UE side, The HFN values for each RB are 

15 preferably set to the START value in the message for 
the corresponding CN domain, and all the data buffers 
are flushed 

£0177] In case of failure, the UE shall send a UTRAN 
MOBILITY INFORMATION FAILURE message (Case \ 
20 and Case 2) 

[01 78} Upon reception of the UTRAN MOBILITY IN- 
FORMATION CONFIRM/FAILURE (Case 1 and Case 
2), the relocation procedure ends 

25 Combined GeWURA Update and SRNS Relocation 
(Seamless Radio Bearers) 

[01/9] The method of the present invention may be 
initiated by the source RNC deciding to perform an 

30 SRNS relocation Steps of this method, which have 
been previously discussed and are re-stated below, are 
shown in greater detail in Fig 1 4 Here, Case 1 repre- 
sents the situation where the user equipment (UE) is not 
involved and Case 2 represents the situation wherein 

35 the UE is involved and a Combined Cell/URA update 
and SRNS relocation is performed 
[0180] In an initial step, an RANAP Relocation Com- 
mand is received by the source RNC from the CN, indi - 
cating the RABs to be released. The source RNC con- 

40 tinues the downlink data transmission on radio bearers 
supporting seamless SRNS relocation until the target 
RNC becomes the serving RNC The target RNC be- 
comes the serving RNC when the RANAP Relocation 
Detect message Is sent 

45 [0181] The target RNC sends a UTRAN MOBILITY 
INFORMATION message (Case 1) on SRBfh (UW 
DCCH) or 5RBtf2 (AM/DCCH), or a CELL/URA UP- 
DATE CONFIRM message (case 2) on SRB#1 (UM/ 
DCCH), which configures the UE with the new U-RNTL 

so [0182] if SRB/r1 is to be used, the target RNC estab- 
lishes the UM RLC entity and the DL HFN value is set 
to the current DL HFN value incremented by one In the 
UM RLC entity, a "Special LI" is preferably used to indi- 
cate that an RLC SDU begins in the beginning of an RLC 

55 PDU 

[0183] If SRBf/2 is to be used, the target RNC estab- 
lishes the AM RLC entity and the DL and UL HFN values 
are set to the current DL and UL HFN values Before 
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sending a UTRAN MOBILITY INFORMATION mes- 
sage, the transmitting side of the AM RLC entity Initiates 
RLC BESET procedure to synchronize the HFN values 
between the UTRAN and UE 

[0184] Upon reception by the UE ol the message, the 
RLC entity lor SRS#2 is (re-)established both on the 
UTRAN and UE sides, and their HFN values are set to 
VALUE Incremented by one {Here, VALUE may be de- 
fined as either the current HFN value or MAX (UL HFN 
of SRB2 i DL HFN of SRB2)) 

[01 85] If the UE has successfully configured itself, II 
shall send a UTRAN MOBILITY INFORMATION CON- 
FIRM message (Case 1 and Case 2), These message 
preferably contain the START values (to be used in In- 
tegrity protection and In ciphering on radio bearers using 
UM and AM RLC) 

[0186] Upon reception and acknowledgment by the 
UTRAN of the message, the UTRAN initiates and the 
UE reinitializes the PDCP header compression entities 
of the radio bearers configured to use a header com- 
pression protocol The RLC entities for affected radio 
bearers (other than SR882) are (reestablished both on 
the UTRAN and UE side The HFN values for each RB 
are preferably set to the START value In the message 
for the corresponding CN domain and ad the data buff- 
ers are flushed In case of failure, the UE shall send a 
UTRAN MOBILITY INFORMATION FAILURE message 
(Case 1 and Case 2). Upon reception of the UTRAN 
MOBILITY INFORMATION CONFIRM/FAILURE mes- 
sage (Case 1 and Case 2), the relocation procedure 
ends 

[0187j I" the foregoing embodiments, to initiate the 
method the UTRAN may transmit a UTRAN MOBILITY 
INFORMATION message to the UE on the downlink 
DCCH using AM or UM RLC In the case of SRNS relo- 
cation, the message may be sent using UM RLC only 

Signaling Radio BearerslRRG Connection Mobility 
Procedures Cell and URA Update Procedures 

[0188] When an RRC message Is transmitted in DL 
on DCCH or CCCH or SHCCH using RLC UM, RRC will 
preferably indicate to the RLC that a special RLC length 
Indicator should be used The UE may assume that this 
indication has been given The special length indicator 
indicates that an RLC SOU begins in the beginning of 
an RLC PDU 

[0189] Reception of a CELL UPDATE/URA UPDATE 
message by the UT RAN based on such a special length 
indicator will now be discussed In accordance with one 
embodiment of the present invention When the UTRAN 
receives a CELL UPDATE/URA UPDATE message, the 
UTRAN: 



1> in me case where the procedure was triggered ^ 
by reception of a CELL UPDATE: 

2> if SRNS relocation was performed: 
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3> transmit a CELL UPDATE CONFIRM 
message on the downlink DCCH 

2> otherwise; 

3> update the START value for each CN 
domain as maintained In UTRAN with 
"START" in the IE "START list" for the CN 
domain as indicated by "CN domain iden- 
tity" in the IE "START list 1 '; 

3> If this procedure was triggered while the 
UE was not In CELLED OH siate, then for 
each CN domain as indicated by "CN do- 
main identity" in the IE "START list"; 

4> set the 20 MSB of the MAC-d HFN 
with the corresponding START value 
in the IE "START list"; 

4> set the remaining LSB of the MAC- 
d HFN to zero. 

3> transmit a CELL UPDATE CONFIRM 
message on the downlink DCCH or option- 
aHy on the CCCH but only if ciphering is not 
required; and 

3> optionally Include the IE "RLC re-estab- 
lish indicator (R85 and upwards)*' to re- 
quest an RLC re-establishment In the UE, 
in which case the corresponding RLC enti- 
ties should also be re-established In 
UTRAN; or 

1> in the case the procedure was triggered by re- 
ception of a URA UPDATE: 

2> if SRNS relocation was performed: 

3> transmit a URA UPDATE CONFIRM 
message on the downlink DCCH 

2> otherwise: 

3> transmit a URA UPDATE CONFIRM 
message on the downlink CCCH or DCCH 

2> include the IE "URA identity" In the URA UP- 
DATE CONFIRM message in a cell where mul- 
tiple URA Identifiers are broadcast, or 

1 > Initiate an RRC connection release procedure by 
transmitting an RRC CONNECTION RELEASE 
message on the downlink CCCH, In particular, the 
UTRAN should: 

2> if the CELL U PD ATE message was sent be- 
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cause of an unrecoverable error in R82, BB3, 
or RB4: 

3> initiate an BRC connection release pro* 
cedure by transmitting an RRC CONNEC- 
TION RELEASE message on the downlink 
CCCR 

Reception of CELL UPDATE CONFIRM/ URA UPDATE 
CONFIRM Message by the UE 

£0t90J When the UE receives a CELL UPDATE CON- 
FIRMS R A UPDATE CONFIRM message; and 

\l the message is received on the CCCH and IE 
"U-RNTl" Is present and has the same value as the 
variable UJWTI; or 

if the message is received on DCCH; 

the UE may; 

- if the CELL UPDATE CONFIRM message includes 
the IE "RLC re-establish indicator (BBS, RB3, and 
RB4) M ; 

* re-establish the RLC entitles for signaling radio 
bearer RB2, signaling radio bearer RB3 and sign- 
aling radio bearer RB4 (if established); 

if the value of the IE "Status" In the variable 
CIPHER1NG_STATUS of the CN domain stored in 
the variable 
LATEST^C ON FIGU RED^CNJDOM At N Is set to 
"Started; 

- set the HFN values for AM RLC entities with RB 
identity 2. RB identity 3 and RB identity 4 (if estab- 
lished) equal to the START value included In the lat- 
est transmitted CELL UPDATE message forihe ON 
domain stored In the variable 
LATEST_CONFlGURED_CN_DOMAIN; 

[01 91 J The foregoing embodiments and advantages 
are merely exemplary and are not to be construed as 
limiting the present invention. The present teaching can 
be readily applied to other types of apparatuses. The 
description of the present invention is intended to be Il- 
lustrative, and not to limit the scope o! the claims. Many 
alternatives, modifications, and variations will be appar- 
ent to those skilled In the art In the claims, means-plus- 
function clauses are intended to cover the structures de- 
scribed herein as performing the recited function and not 
only structural equivalents but also equivalent struc- 
tures 



40 
Claims 

1 r A method for performing SRNS relocation, compris- 
ing: 

5 

receiving In a target RNC radio resource Infor- 
mation from a source RNC, said radio resource 
information including a ciphering parameter; 
modifying the ciphering parameter to coincide 

10 with a deciphering parameter of a user terminal, 

said deciphering parameter corresponding to 
one the user terminal uses when out-of -se- 
quence data is received; 
ciphering a data unit based on the modified ci- 

15 phering parameter; and 

transmitting the ciphered data unit from the tar- 
get RNC to the user terminal 

2. The method of claim 1 , wherein the target RNC and 
2D the user terminal are operating In UM mode 

3. The method of claim 2, further comprising: 

transmitting the ciphered data unit over a serv- 
es Ing radio bearer SRB1 

4. The method of claim 2, further comprising: 

transmitting the ciphered data unit over a UM 
30 DCCH channel 

5. The method of claim 1 , wherein said out-of-se- 
qua nee data includes data having a transmission 
sequence number which does not consecutively foi- 

35 low a transmission sequence number of a last PDU 
transmitted from the source RNC to the user termi- 
nal 

6. The method of claim 1 , wherein the ciphering pa- 
40 rarneter and said deciphering parameter are HFN 

parameters 

7. The method of daim 1 , wherein said modifying step 
includes: 

45 

adjusting an HFN value of the ciphering param- 
eter to equal an HFN value of said deciphering 
parameter when said out-of-sequence data is 
received 

50 

8. The method of claim 7. wherein said adjusting step 
Includes: 

incrementing the HFN value of the ciphering 
55 parameter to equal an incremented value of 

said deciphering parameter. 

9. The method of claim 1 , wherein the transmitting 



EP1 337 125 A2 



21 



41 



BP 1 337 125 A2 



42 



step includes: 

transmitting a data start Indicator with the ci- 
phered data unit. 

1C The method of claim 9, wherein said data start In- 
dicator indicates that the ciphered data unit Is not 
included as part of an SDU previously transmitted 
to the user terminal 

11. A method for performing SRNS relocation, compris- 
ing: 

receiving In a target RNC radio resource infor- 
mation from a source RNC; and 
transmitting a data unit from the target RNC to 
a usertermfna!, said data unit including a trans- 
mission sequence number which consecutively 
follows a transmission sequence number of a 
data unit last transmitted from the source RNC 
to the user terminal. 

12 . The method of claim 11 , further comprising: 

ciphering the data unit before said transmitting 
step 

13.. The method of claim 1 2 t wherein the ciphering step 
includes: 

ciphering the data unit with a same ciphering 
parameter the user terminal used to decipher a 
data unit transmitted from the source RNC to 
the user terminal 

14. The method of claim 13, wherein said same cipher- 
ing parameter includes a same HFN value 

15. The method of claim 11, wherein the target RNC 
and the user terminal are operating in UM mode 

16. The method of claim 11 , further comprising; 

transmitting the data unit over a UM DCCH 
channel. 

17., The method of claim 11, further comprising: 

transmitting the data unit over a serving radio 
bearer SRB1 . 

18. The method of claim 11, wherein the transmitting 
step Includes; 

transmitting a data start indicator with the data 
unit 

19, The method of claim 18, wherein said data start in- 



dlcator Indicates that the data unit is not included 
as part of an SDU previously transmitted to the user 
terminal. 

5 20 A method for performing SRNS relocation, compris- 
ing: 

resetting transmission information of a target 
RNC; and 

io transmitting a message instructing a user ter- 

minal io reset reception information to values 
which coincide with said reset transmission in- 
formation of the target RNC 

15 21 „ The method of claim 20, wherein said resetting step 
Includes resetting a transmission sequence number 
to an initial value in the target RNC, and wherein 
said reset reception Information includes a trans- 
mission sequence number of a next-expected data 

20 unit set to said initial value 

22 The method of claim 20, wherein said resetting step 
includes resetting a state variable to an Initial value 
In the target RNC, and wherein said message in* 
25 eludes Information Instructing the user terminal to 
be set to said state variable. 

23. The method of claim 20 r wherein said message Is 
an unciphered message . 

30 

24, The method of claim 20, further comprising: 

receiving a message from the user terminal in- 
dicating that the user terminal has reset said 
35 reception Information. 

25-. The method of claim 20, wherein said resetting step 
includes setting a ciphering parameter to an initial 
value, and wherein said reset reception information 
40 Includes a deciphering parameter which coincides 
with the initial value of said ciphering parameter. 

26. The method of claim 25, wherein said ciphering pa- 
ramsterand said deciphering parameter include a 

45 same HFN value, 

27. The method of claim 20, wherein said resetting step 
includes flushing SDUs in the target RNC and 
wherein said message instructs the userterminai to 

so flush SDUs. 

28, The method of claim 20, further comprising: 

transmitting a data unit from the target RNG to 
55 the user terminal over a serving radio bearer 

SRB2- 

29, The method of claim 20, wherein the target RNC 
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and the user terminal are operating in AM mode 

30. The method of claim 29, further comprising; 

transmitting a ciphering parameter and trans- 
mission sequence number information from a 
source RNC to the target RNC, wherein said 
ciphering parameter coincides with a decipher- 
ing parameter used in the user terminal and a 
ciphering parameter the source RNC used to 
transmit a data unit to the user terminal, and 
wherein said transmission sequence number 
information is indicative of a nexl -expected 
transmission sequence number in the user ter- 
minal 

31. The method of claim 20, further comprising: 

transmitting a data unit from the target RMC to 
the user terminal, said data unit Including a data 
start indicator indicating that the data unit Is not 
included as part of an SDU previously transmit- 
ted to the user terminal 

32. The method of claim 20, further comprising: 

transmitting a data unit from the target RNC to 
the user terminal over an AM DCCH channel 

33. A method for performing SBNS relocation, compris- 
ing: 

delivering radio resource information from a 
source RNC to a target RNC in a UTRAN, said 
radio resource information Including: 

a) a ciphering parameter the source RNC 
used to transmit POUs to a user terminal, 
and 

b) a transmission sequence number corre- 
sponding to one of a next PDU to be trans- 
mitted by the source RNC to a user termi- 
nal or a lest PDU that was transmitted from 
the source RNC to the user terminal; 

generating a PDU/RRC message based on 
said transmission sequence number; 
ciphering the PDU/RRC message with said ci- 
phering parameter; and 
transmitting the ciphered message from the tar- 
get RNC to a user terminal 

34. The method of claim 6, wherein the target RNC and 
the user terminal are operating in AM RLC mode 

35.. A method for performing a relocation procedure In 
a communications system, said communications 
system Including a transmitter and a receiver; said 



method comprising: 

Initializing the transmitter to communicate with 
the receiver, said initializing step including set- 
5 ting a transmission sequence number to a first 

value and setting a deciphering parameter to a 
second value; 

transmitting a PDU including said initial se- 
quence number and said deciphering parame- 
10 ter from the transmitter to the receiver; 

determining, in the receiver, that the initial se- 
quence number in the PDU does not equal a 
next sequence number expected by the receiv- 
er; 

15 setting a deciphering parameter in the receiver 

to the second value; and 
deciphering the PDU, 

36, A transmission unit, comprising: 

20 

a target RNC which receives radio resource In- 
formation from a source RNC, said radio re- 
source information including a ciphering pa- 
rameter; and 

25 a processor which modifies the ciphering pa- 

rameter to coincide with a deciphering param- 
eter of a user terminal, and which ciphers a data 
unit based on the modified ciphering parame- 
ter; and 

30 a transm ftter wn ich transm its the ciph ered data 

unit from the target RNC to the user Terminal, 
wherein said deciphering parameter corre- 
sponding to one the user terminal uses when 
out-of -sequence data is received 

35 

37. The transmission unit of claim 36, wherein the tar- 
get RNC and the user terminal are operating in UM 
mode, 

ao 38, The transmission unit of claim 37, wherein the 
transmitter transmits the ciphered data unit over a 
serving radio bearer SRBt 

39, The transmission unit of claim 36, wherein the 
45 transmitter transmits the ciphered data unit over a 

UM DCCH channel 

40, The transmission unit of claim 36, wherein said out- 
of-sequence data includes data having a transmis- 

so slon sequence numberwhich does not consecutive- 
ly follow a transmission sequence number of a fast 
PDU transmitted from the source RNC to the user 
terminal. 

55 41, The transmission unit of claim 36, wherein the ci- 
phering parameter and said deciphering parameter 
are HFN parameters. 
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42. The transmission unit of claim 36, wherein said 
processor adjusts an HFN value of the ciphering pa- 
rameter to equal an HFN value of said deciphering 
parameter when said out~of-sequence data is re- 
ceived 

43., The transmission unit of claim 42, wherein said 
processor increments the HFN value of the cipher- 
tag parameter to equal an Incremented value of said 
deciphering parameter 

44, The transmission unit of claim 36, wherein the 
transmitter transmits a data start indicator with the 
ciphered data unit 

45, The transmission unit of claim 44, wherein said data 
start indicator indicates that the ciphered data unit 
is not included as part of an SOU previously trans- 
mitted to the user terminal 

46, A transmission unit, comprising: 

a target RNC which receives radio resource in- 
formation from a source RNC; and 
a transmitter which transmits a data unit from 
the target RNC to a user terminal, said data unit 
including a transmission sequence number 
which consecutively follows a transmission se- 
quence number of a data unit last transmitted 
from the source RNC to the user terminal 

47, The transmission unit of claim 46, further compris- 
ing: 

a processor which ciphers the data unit before 
transmission 

48, The transmission unit of claim 47, wherein the proc- 
essor ciphers the data unit with a same ciphering 
parameter the usertermlnal used to decipher a data 
unit transmitted from the source RNC to the user 
terminal 

49, The transmission unit of claim 48, wherein said 
same ciphering parameter includes a same HFN 
value 

50, The transmission unit of claim 4B r wherein the tar- 
get RNC and the user terminal are operating In UM 
mode 

61- The transmission unit of claim 46, wherein the 
transmirtertransmits the data unit over a UM DCCH 
channel 

52 The transmission unit of claim 46, wherein the 
transmitter transmits the data unit over a serving ra- 
dio bearer SRBt , 



53 The transmission unit of claim 46, wherein the 
transmitter transmits a data start indicator with the 
data unit 

5 54. The transmission unit of claim S3, wherein said data 
start indicator indicates that the data unit is not in- 
cluded as part of an SOU previously transmitted to 
the user terminal, 

10 55, A method for performing SRMS relocation, compris- 
ing: 

receiving in a target RNC an RNSAF Reloca- 
tion Commit message from a source RNC, said 
13 message including an HFN ciphering parame- 

ter; 

modifying the HFN ciphering parameter to co- 
incide with an HFN parameter of a UE, said UE 
HFN parameter corresponding to one the UE 

so uses when an out-of -sequence PDCP se- 

quence number Is received; 
ciphering an RIG PDU based on the modified 
HFN ciphering parameter; and 
transmitting the ciphered RLC PDUE from the 

25 target RNC to the UE 

56, The method of claim 55, wherein the target RNC 
and the UER are operating in UM mode. 

so 57. The method of claim 56, further comprising: 

transmitting the ciphered RLC PDU over a serv- 
ing radio bearer SRB1 

35 aa The method of claim 56, further comprising: 

transmitting the ciphered RLC PDU over a UM 
DCCH channel. 

40 59. The method of claim 55, wherein said out-of-se- 
quence PDCP sequence number does not consec- 
utively follow a PDCP sequence number of a last 
RLC PDU transmitted from the source RNC to the 
UE. 

45 

60. The method of claim 55, wherein said modifying 
step Includes: 

adjusting a value of the HFN ciphering param- 
so eter to equal a value of said UE H FN parameter 

when said out-of-sequence PDCP sequence 
number is received.. 

61. The method of claim 60, wherein said adjusting step 
55 includes: 

incrementing the HFN ciphering parameter to 
equal an incremented value of said UE HFN pa 
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rameter. 

62. The method of claim 55, wherein the transmitting 
stop includes: 

transmitting a START value with the ciphered 
RLC PDU , said START value Indicating that the 
ciphered RLC PDU Is not included as part of an 
SDU previously transmitted to the UE 

63. A method ot sending information in a mobile radio 
communication system comprising: 

receiving the information including the numbers 
related to a ciphering sequence number and 
the state variable of a radio link control entity of 
a radio network controller which was previously 
a serving radio network controller of a terminal; 
establishing a radio link control entity for send- 
ing information to said terminal; 
setting the state variable of a radio link control 
entity synchronized with said received state 
variable; and 

sending a data unit of said Information starting 
with the state variable to said terminal 

64.. A method of claim 63, further comprising: 

setting an indicator indicates that a service data 
unit contains the Wormattonbegiris in the be- 
ginning of a data unit of said radio link control 
entity. 

BB, A method of claim 63, wherein, one of the state var- 
iables of a radio link control entity Is the sequence 
number of the RLC PDU to be transmitted next time. 

66. A method of claim 65, wherein, one of the state var- 
iables of a radio link control entity Is the most prior 
sequence number of the RLC PDU to be retrans- 
mitted 



network controller; setting a length indicator in- 
dicates that an RLC SDU begins In the begin- 
ning of an RLC PDU; and 
sending information ciphered with the ciphering 
s sequence number through said radio link con- 

trol entity to said terminal 

69 A method of sending Information In mobile radio 
communication system comprising: 

10 

receiving down link radio resource control mes- 
sage on signalling radio bearer; 
checking She serving radio network controller 
changes; 

15 changing hyper frame number value for anoth- 

er signalling radio bearer; and 
transmitting up link radio resource control mes- 
sage ciphered with a number from the changed 
hyper frame number 

20 

70 A method of claim 69, further comprising: 

sending a predetermined value for the hyper 
frame number to the serving radio network con- 
25 irolter; and 

establishing other signalling radio bearers with 
said predetermined value. 

71. A method of claim 70, wherein said predetermined 
30 value is the start value of the hyper frame number 

72, A method of claim 69, wherein the changed hyper 
frame number value is current value + 1 

35 73, A method of claim 69, wherein the changed hyper 
frame number value is the larger value between 
those of uplink and downlink + 1 



40 



67, A method of claim 64, further comprising; sending 
an Instruction for moving the receiving window to 
said terminal . 45 

68 A method of sending information in a mobile radio 
communication system comprising; 

receiving the Instruction which Instructs to be- so 
come the serving radio network controller of a 
terminal from core network with the information 
including the numbers related to a ciphering se- 
quence number; 

establishing a radio link control entity for signal- & 
ling control Information to said terminal; 
setting the ciphering sequence number accord- 
ing to said numbers received from other radio 
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